Hide Idle (>14 d.) Chans
← 2022-01-05 | 2022-01-08 → ↓
shinohai[billymg]: mod6: can u see me?
shinohai[billymg]: good eve #pest
signpost[billymg] tips hat at shinohai
awt[billymg]: mornin'
shinohai[billymg]: Trying to get mod6 connected, everything *looks* proper but still can't dm him
whaack[billymg]: shinohai: any chance you derp'd like me and sent the same key to multiple peers?
shinohai[billymg]: hmm whaack lemme check - I gen'd new key for mod6 tho
whaack[billymg]: prob not then
asciilifeform[billymg]: mod6: let's see if worx
asciilifeform[billymg]: nope, 'no packets received'
asciilifeform[billymg]: he must be behind nat
asciilifeform[billymg] added his ip:port to at, still nodice
asciilifeform[billymg]: still 'no packets received' from mod6
asciilifeform[billymg]: very odd, my station is getting (per debug log) packets from his, but none of'em decode
asciilifeform[billymg]: still apparently same thing (getting packets from his station but they all pass as 'ignore')
asciilifeform[billymg]: still same thing
asciilifeform[billymg]: awt when you come back, see if you can help him debug
asciilifeform[billymg]: ( asciilifeform's station sees packets from mod6's, but nuffin decodes to a msg )
asciilifeform[billymg]: loox like the reverse also tru
asciilifeform[billymg]: ruled out, seems, mismatched keys (he started w/ a clean wot)
billymg: awt, whaack: you guys seen this yet? saw it here
billymg: looks like the app is just a lightning wallet, but the branding of the project is clearly meant to make it sound similar to the "Bitcoin Beach" project in El Salvador
billymg: the article mentions there'll also be a "Bitcoin Lake" launching in Guatemala this month
signpost[billymg]: billymg: iirc bukele said two other countries were going to accept bitcoin as legal tender in 2022
signpost[billymg]: costa rica and guatemala would make sense
billymg: would be awesome if true
billymg: i've been meaning to set up a lightning node in order to see what it's like but haven't gotten around to it yet. i have a synced prb ready to go for that purpose, maybe i'll move it up the priority list so i can make a trip down the coast to check this out
signpost[billymg]: something *like* lightning doesn't even seem like a bad thing, just didn't need to be built atop segwit.
billymg: signpost: btw it's weird that we aren't peered even though i entered your info, but not that weird since asciilifeform and awt are still the only users i've been able to peer directly with
billymg: despite having tried with everyone else in here
signpost[billymg]: do you have more than one party in this state in your pest wot?
signpost[billymg]: if so probably that bug I found
billymg: what do you mean by 'more than one party in this state'?
billymg: as in, users that i have at and key entries but somehow don't peer directly?
billymg: yeah, everyone except asciilifeform and awt
signpost[billymg]: blatta currently thinks these are duplicate names
billymg: which are duplicates?
signpost[billymg]: any which have not yet received packets, if there is more than one name that has not.
signpost[billymg]: lemme get you the line to hax, sec
billymg: (sorry i must have missed the earlier discussion of this bug, and possibly a thread the bot didn't pick up)
billymg: re: lightning on top of segwit, yeah, it's unfortunate, but i figure it can be used the way one carries cash in their wallet, i.e. never more than what they would feel comfortable losing
signpost[billymg]: I wont sign because awt may want to refactor this in another way, but it fixes the bug.
whaack[billymg]: billymg: had not seen the dominical bitcoin project yet, but i have heard that bitcoin beach is a bit of a disaster, specifically i heard that a common wallet (name escapes me) that they (i.e. the people who style themselves as bitcoin ambassadors) set people up with lots people's coins. whether that was because of user er
billymg: alright, lemme try this out, brb one sec
whaack[billymg]: the drag-everyone-we-can-into-bitcoin mentality does more harm then good
whaack[billymg]: signpost: that was the one
whaack[billymg]: something like ln ==== deedbot wallet
signpost[billymg]: to take the other side, somebody's got to make the move toward practical use.
billymg: without every food cart, bnb, hardware store, etc. etc. accepting btc then the only way to use it is to go through an enemy controlled chokepoint first
signpost[billymg]: sure, and without transiting enemy territory no new nation was ever born
billymg: sending lighting sats to fruit vendor is still using enemy territory though (fritz phone and cell tower), it's just fragmenting and distributing the activity enough to increase their cost of engagement
billymg: lightning*
whaack[billymg]: but the angle is not to attack small targets like jorge's fruit stand, it's to be able to get big suppliers to accept large transactions for btc, the former just results in a lulzfest
signpost[billymg]: yup, I'm making no defense of lightning, though there are ideas in it that aren't casually dismissable, could in principle exist atop trb too, without segwit.
billymg: btw, i'm on the patched version now. will i need to redo the peering steps to fix my AT?
signpost[billymg]: maybe, not sure. give it a try
signpost[billymg]: whaack: I dunno man, this cynical view is not one I share.
signpost[billymg]: like I said, have to start somewhere shitty.
asciilifeform[billymg]: signpost: iirc orig scheme in 'lightning' (naturally implemented via various prbisms) was to 'hawala' b/w 2 noades to save on tx fees.
asciilifeform[billymg]: (similar to how national banks do not often actually move gold bricks but instead keep tally)
asciilifeform[billymg]: i.e. rather like a vast rube goldberg attempt at clone of signpost's walletron
signpost[billymg]: yep, fund a multisig addy and ratchet forward txn that adjust balance of same back to originators, without broadcasting txn
signpost[billymg]: anyone broadcasts, "channel" is done
signpost[billymg]: this doesn't need any of the other piled-on shit
asciilifeform[billymg]: signpost: come to think of it, potential fyootoor pest knob
asciilifeform[billymg]: doesn't need to involve trb directly
asciilifeform[billymg]: simply needs 2 peers to trust ea. other enuff to eventually settle acct when asked
asciilifeform[billymg] not 100% certain whether it'd win over what he already does w/ isp customers informally, say
billymg: ok, i think i'm back in
whaack[billymg] hears you loud and clear through peers signpost and asciilifeform
billymg: !. uptime
bitbot: billymg: time since my last reconnect : 0d 0h 0m
billymg: boo
asciilifeform: hm i've an at entry for it nao
asciilifeform: billymg: maybe need to set its 'cut' to something higher than 3
bitbot: Logged on 2022-01-08 00:58:44 bitbot: billymg: time since my last reconnect : 0d 0h 0m
billymg: but i didn't see it in my console
asciilifeform: me neither
asciilifeform: !. uptime
bitbot: asciilifeform: time since my last reconnect : 0d 0h 3m
asciilifeform: shows in billymg's log but not in asciilifeform's console
billymg: is the 'cut' value a startup flag?
billymg: the bounces cutoff, right?
asciilifeform: but apparently cmd not yet implemented in blatta
asciilifeform: it's a 'knob', 'max_bounces'
asciilifeform: try /quote knob max_bounces 5
billymg: i'd have to do this while connected to the bot's station though
asciilifeform: (or via sqlite console)
asciilifeform: it's in 'knobs' table
billymg: ah neat
billymg: seems easier in this case
asciilifeform: come to think of it, max_bounces wouldn't explain why bot logs but we aint seeing its echos
asciilifeform: !. uptime
bitbot: asciilifeform: time since my last reconnect : 0d 0h 8m
asciilifeform set his own max_bounces to 5 and still aint seeing
billymg: right, was thinking the same thing, wouldn't need any bounces since we're peered directly with it
asciilifeform: for that matter, bounce distance of asciilifeform and bitbot is 1
asciilifeform sets own back to 3
billymg: anyone else here see bitbot's echos in their console?
asciilifeform: nfi what's going on there
asciilifeform suspects dedupe bug
billymg: btw for the above thread that got lost if anyone wants to send it over in a paste i'll manually add it to the log
billymg: seemed like we were having a good discussion
asciilifeform: for that matter may explain the thing w/ mod6's station similarly
asciilifeform: i.e.a dedupe bug which somehow removes the ~last~ copy of a msg
billymg: i'll have to look at the station's logs a little later, about to sit down to dinner
asciilifeform also bbl
billymg: re-added and keyed signpost with the patched state.py, will see if that works
signpost[asciilifeform|billymg]: billymg: give AT signpost 96.43.130.234:7778 a try
signpost[asciilifeform|billymg]: so far doesn't appear I am receiving packets from you
billymg: signpost: same here, and that's the same address i have in the AT: "signpost 96.43.130.234:7778 no packets received from this address"
billymg: bot appears properly peered asciilifeform now at least: http://logs.bitdash.io/pest/2022-01-08#1001988
bitbot: Logged on 2022-01-08 01:21:07 signpost[asciilifeform|billymg]: so far doesn't appear I am receiving packets from you
bitbot: whaack[asciilifeform|billymg]: time since my last reconnect : 0d 0h 28m
billymg: whaack: do you see the echo in your console? i only see it in the log
bitbot: Logged on 2022-01-08 01:26:09 bitbot: whaack[asciilifeform|billymg]: time since my last reconnect : 0d 0h 28m
signpost[asciilifeform]: billymg: maybe send me your ip and port, and I'll try your direction?
billymg: 205.134.172.29:7778
billymg: signpost ^
billymg: still got that as hearsay
signpost[asciilifeform|billymg]: yeah, and I'm receiving you as hearsay. however I do see your IP in my logs.
signpost[asciilifeform|billymg]: AT says I still haven't received packets from you
signpost[asciilifeform]: billymg: firewall on your end by chance? my logs look like I'm sending to you, but not receiving
billymg: i have the same issue with shinohai jonsykkel PeterL
billymg: i've only been able to peer with asciilifeform awt and bitbot
billymg[asciilifeform]: i've only been able to peer with asciilifeform awt and bitbot
billymg: signpost: i never configured any extra firewall on this box, it's just the standard dulap
billymg: not sure if it's got something configured by default that could be causing issues though
whaack[asciilifeform]: http://logs.bitdash.io/pest/2022-01-08#1001992 <<-- i don't see the echo, i only see the msg in the log
bitbot: Logged on 2022-01-08 01:26:09 whaack[asciilifeform|billymg]: !. uptime
billymg: !. uptime
bitbot: billymg: time since my last reconnect : 0d 0h 3m
billymg: there it is
billymg: earlier i only restarted the bot's pest station, to peer it with asciilifeform. i didn't restart the bot itself
billymg: in theory that *shouldn't* have had an effect on the bot
billymg: the bot's logs showed the normal series of 'connecting' 'connection refused' until finally a 'connected' when the pest station came back up
awt[asciilifeform]: wow that unpeer bug is nasty
awt[asciilifeform|billymg]: leaves orphaned keys in the db
awt[asciilifeform]: issue was mod6's clock was off
mod6[billymg|asciilifeform]: Thank you awt, much appreciated. I'll come back tomorrow, add a few more peers & keys. Cheers!
asciilifeform: welcome to pestnet, mod6 !
asciilifeform: awt: good catch re: clock. this prolly oughta be part of 'pre-flight checklist' for new station setup.
asciilifeform: (once we have actual docs..)
asciilifeform: oddly enuff asciilifeform's station still shows 'no packets received...' for mod6 in AT
asciilifeform: currently seeing him via mod6[awt|jonsykkel|billymg]
awt[asciilifeform]: actually mine too hrm
awt[asciilifeform|billymg]: although I'm getting messages directly from mod6
asciilifeform: per my station's AT, apparently i've not received any
asciilifeform: (unless the AT timestamp thing is buggier than i thought)
awt[asciilifeform|billymg]: seems buggier than you thought since it's not updating for me and I definitely received messages from him
asciilifeform: this is even stranger
bitbot: Logged on 2022-01-08 03:10:02 mod6[asciilifeform]: :}
asciilifeform: i.e. bitbot indicates having received a mod6 msg from asciilifeform
asciilifeform: then again may well correspond to my mod6[awt] | :}
awt[asciilifeform]: possibly not updating the timestamp at all since 9983
asciilifeform: so doesn't contradict the observation that asciilifeform's station still not received msg from mod6
asciilifeform goes to restart pestron, maybe is a peculiar wedge state..
asciilifeform: still 'no packets received..' re mod6
asciilifeform to bed soon, has to meet construction folx at new pad in the wee hours
asciilifeform: !. uptime
bitbot: asciilifeform: time since my last reconnect : 0d 1h 45m
asciilifeform: heh at least this worx nao
awt[asciilifeform]: ok fixed the timestamp update issue locally
awt[asciilifeform]: now updates on every received message including rubbish
asciilifeform: awt: asciilifeform was thinking, the [x|y|z] thing prolly oughta behave slightly differently: should only count the peers who gave same (min(all copies)) bounce# of the msg
asciilifeform: otherwise in fact misleading
asciilifeform: does this make sense to you?
asciilifeform: the orig. purpose of that thing was to try and show how many peers may be relaying an authentic (i.e. immediate) copy of msg
asciilifeform: whereas atm you can have the case where only 1 in fact received directly from $peer, but some arbitrary subset of your wot is relaying an n-th bounce copy from that one back to you
asciilifeform will update spec later
asciilifeform: this was prompted by seeing mod6[awt|jonsykkel|billymg] while afaik jonsykkel not yet peered w/ mod6
awt[asciilifeform|billymg]: yes this makes sense. so exclude handles that relayed with higher than the lowest number of bounces
asciilifeform: if awt agrees that this makes sense, i'ma amend the spec (later this wknd)
awt[asciilifeform]: actually yes now the whole idea makes more sense
asciilifeform: such observations are made possible by having an actual draft proggy! ty again for baking it, awt
asciilifeform: prolly this aint the last mechanism that'll need tuning prompted by actual field tests.
awt[asciilifeform]: con gusto!
asciilifeform: overall helps to remember that a msg can take 'winding' path from orig -> dest
asciilifeform: (which, depending on what the default 'cut' ends up being in later pestrons, can be quite long)
asciilifeform: the current '3' asciilifeform pulled outta own arse
whaack[asciilifeform]: http://logs.bitdash.io/pest/2022-01-08#1002059 <-- makes sense, i agree this should be added.
bitbot: Logged on 2022-01-08 03:43:07 awt[asciilifeform|billymg]: yes this makes sense. so exclude handles that relayed with higher than the lowest number of bounces
whaack[asciilifeform|billymg]: asciilifeform and awt: this proggy is super neat, thanks for writing the spec/draft
whaack[asciilifeform|billymg]: also awt i have to check this, but i think the NOTICE messages being sent out by blatta are ill formatted to the irc spec
← 2022-01-05 | 2022-01-08 → ↑
Random(pest) | Download hourly DB snapshot | Get Source Code