whaack: !e view-height
trbexplorer: block_height: 720763
trbexplorer: mins_since_last_block: 7
asciilifeform: $ticker btc usd
asciilifeform: ah lol bot awol
asciilifeform: !w poll
watchglass: Polling 14 nodes...
watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.082s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.086s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=720764
watchglass: 205.134.172.26:8333 : Alive: (0.141s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=720764
watchglass: 205.134.172.27:8333 : Alive: (0.092s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764 (Operator: asciilifeform)
watchglass: 54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.112s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.133s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764 (Operator: asciilifeform)
watchglass: 205.134.172.28:8333 : Alive: (0.083s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=720764 (Operator: whaack)
watchglass: 208.94.240.42:8333 : Alive: (0.204s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.312s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 94.176.238.102:8333 : (2ppf.s.time4vps.cloud) Alive: (0.376s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720319
watchglass: 82.79.58.192:8333 : (static-82-79-58-192.rdsnet.ro) Alive: (0.320s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.556s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 75.106.222.93:8333 : Alive: (0.439s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764
watchglass: 143.202.160.10:8333 : Busy? (No answer in 100 sec.)
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076948 << "i am" messages would be part of chain like so? (blue arrows refering to this)
dulapbot: Logged on 2022-01-27 13:27:45 asciilifeform: thimbronion, jonsykkel : asciilifeform had a thought : possibly the inclusion of 'speaker' field to start with was a mistake. instead, internally station oughta distinguish l2+ msgs by ~chain~, internally, and 'speaker' instead would be a 'call me x' ~broadcast message type~.
dulapbot: Logged on 2022-01-27 13:50:48 asciilifeform: btw if the 32bytes formerly 'speaker' instead made to point to one's 'birth' (i.e. 1st 'i am' broadcast), makes rather simple to determine who was 1st claimant of $handle on given pestnet.
jonsykkel: i think idea of prog internally doing "identity == chain" for l2+ is good
jonsykkel: if get rid of speaker field, need to have the last "i am" msg to know speaker of a given msg. would think in practice means a lot of getdata necesary before can even display l2+ messages. could of cours have smth like special getdata for last "i am" paket
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076949 << could work as long as have strict rules for when to mess with text ("s/^speaker: /etc/" or smth) so doesnt fuck text up unpredictably midsentence
dulapbot: Logged on 2022-01-27 13:29:18 asciilifeform: would solve e.g. this, supposing one were willing to have the machine substitute a chain id munge in place of the speaker yer addressing, and parse it back out on the receiving end
jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076878 << although on 2nd thought maybe this is mostly an imaginary problem, would almost never happen and presumably be resolved relatively quickly if does happen. xtra complexity required to handle this might be unwarranted, idk.
dulapbot: Logged on 2022-01-27 02:40:39 jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-26#1076775 << if net1 sees guy1 as "speaker" and guy2 as "speaker-2", and net2 sees guy1 as "speaker-2" and guy2 as "speaker" - how to address these ppl in messages? "hey speaker-2 wats up" << will appear to diff subnets that u are addressing diff guys
cgra: this is again starting to take time beyond imagination, so i thought i'd make an attempt to loosely describe meanwhile, perhaps asciilifeform grasps what i mean:
dulapbot: Logged on 2021-12-06 10:00:57 cgra: asciilifeform: i'll just make a blog piece of this too, sometime soon(ish)
cgra: the message exchanges "getblocks"/"inv" and "getheaders"/"headers" are similar, but the former ends up being pretty clumsy in practice. also, ofc, the latter otoh isn't currently fully implemented
cgra: getblocks/inv exchange sucks because the inv response may end up distorted at least for: 1) new best block(s) mixing up with it, 2) the inv spam guard, by preventing repeats, will cause gaps, and in the worst case, stuck sync, 3) unlike the "headers" message, it's not an explicitly described hash segment of the block chain, just a list of block hashes, so any mixups and gaps are not obvious
cgra: the proposed approach is to, instead of sending "getblocks", send "getheaders". no change in how to respond to other nodes' "getblocks", only change how own node requests new blocks. then, "AskFor()" blocks according to "headers" responses, not "inv" messages. on "inv" messages, can just reply with "getheaders" to get a more reliable "block advert": a "headers" message, and now further "AskFor()"
cgra: while the "headers" message's item count isn't regulated by the originating node, like an "inv" in reply to "getblocks" is (to allow the receiving node to request the whole advertised list of blocks at once), the "headers" recipient could simply ask for one block at a time and repeat "getheaders" on new block reception
cgra: the unbounded "headers" message is ~160kB in size, but the node asking for blocks could use an occasionally updated stop hash, seems like some 63 blocks ahead of the first in the unbounded headers list would give an optimal, average "headers bandwidth". every time the stop hash is reached, another unbounded headers is requested, and new stop hash is decided.
cgra: this "one block at a time" approach could afaik mean ~zero bastards and ~zero blocks out-of-order. the downside is that blocks are processed ~and~ downloaded synchronously. next block is requested only after the previous one is fully processed, not simultaneously
cgra: while admittedly headers-first-esque, i suppose some 3-5MB block buffer wouldn't hurt, if a reasonably clean implementation exists, to allow parallel processing and download of blocks
asciilifeform: wb jonsykkel & cgra !
jonsykkel: ty ty
dulapbot: Logged on 2022-01-28 13:10:19 jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076948 << "i am" messages would be part of chain like so? (blue arrows refering to this)
asciilifeform: jonsykkel: except, the 'i am bobart' will point to 'i am bob' (in a designated chain field)
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077015 << where was previously 'speaker' field, nao a hash which points to last 'i am'. and you getdata it w/ ordinary getdata if you dun have it.
dulapbot: Logged on 2022-01-28 13:10:59 jonsykkel: if get rid of speaker field, need to have the last "i am" msg to know speaker of a given msg. would think in practice means a lot of getdata necesary before can even display l2+ messages. could of cours have smth like special getdata for last "i am" paket
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077018 << 'rule 1' of network protocols -- it sumthing can happen, it ~will~ happen
dulapbot: Logged on 2022-01-28 13:11:26 jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-27#1076878 << although on 2nd thought maybe this is mostly an imaginary problem, would almost never happen and presumably be resolved relatively quickly if does happen. xtra complexity required to handle this might be unwarranted, idk.
asciilifeform: esp. if that 'sumthing' breaks you.
asciilifeform: esp. if it breaks you w/out being readily attributable to the breaker.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077027 << the problem here is that all known noades afaik send 'their latest' block unsolicited to all peers. 99%+ of the 'bastards' received by a syncing noad, are these
dulapbot: Logged on 2022-01-28 13:29:36 cgra: this "one block at a time" approach could afaik mean ~zero bastards and ~zero blocks out-of-order. the downside is that blocks are processed ~and~ downloaded synchronously. next block is requested only after the previous one is fully processed, not simultaneously
jonsykkel: it will happen, but not catastrophic event? at most some confusion between you and couple of l2+ ppl as far as i can tel
asciilifeform: i.e. not that it wouldn't help to send a smarter 'getdata' (speaking of cgra re trb ftr) but it won't cut most of the incoming noise.
asciilifeform: jonsykkel: asciilifeform's pov is that if hearsay can't be decacophonized, it is largely useless
jonsykkel: right, but would still be decacophonized when reading, confusion only occurs if try address collided ppls
jonsykkel: autoreplacing handles in messages text carries own uglyness
asciilifeform: the focus there is to get folx to quit colliding asap. 1 way or anuther.
asciilifeform agrees that substituting handles in msg text is an ugh
jonsykkel: indeed
cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077040 << they send an "inv" of the latest block (ie. not the block itself), which you needn't "AskFor()" in response, send "getheaders" instead and proceed from there.
dulapbot: Logged on 2022-01-28 13:43:36 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077027 << the problem here is that all known noades afaik send 'their latest' block unsolicited to all peers. 99%+ of the 'bastards' received by a syncing noad, are these
asciilifeform: cgra: the wisdom, such as it was, of the orig. approach (where you get blox thrown at you constantly whether you actually want the 'latest' or not) was the difficulty of sending you into a 'cave' of pregenned alt-universe blox
dulapbot: Logged on 2022-01-26 19:16:32 asciilifeform: this is similar to the 'trb in cave' problem.
asciilifeform: cgra: prb's 'headers 1st' approach makes it trivial
asciilifeform: (to do it to a freshly-built noad, that is)
asciilifeform: 'headers-1st'ism -- at least as seen in prb -- effectively forces you to uncritically accept lengthy chain from 1 peer at a time when syncing
cgra: asciilifeform: imo this isn't headers-firstism, why do you think so?
asciilifeform may be missing sumthing
cgra: isn't any more headers-firstism than the getblocks/inv is -- first asking for hashes, then receiving a bunch of them in response
cgra: asciilifeform: to me an 'unsolicited block' is a concrete block being thrown at me, not an inv advert of one. what's 'unsolicited block' to you?
cgra: afaik not many concrete blocks get thrown around, while plenty inv adverts flying
asciilifeform will have to reread the sores & come back to this thrd
asciilifeform not touched trb gearbox in a depressingly long time
cgra: asciilifeform: i suspect you've forgotten something about the 'inv' mechanism
cgra: (otoh, my head being solid bone not ruled out as a possibility either)
asciilifeform: no, i remember that it exists, but also iirc most of the blox received by trb aint from getdata per se
asciilifeform: i.e. it never getdata'd for'em from a previously-recv'd inv
cgra: asciilifeform: my test node was always behind a nat...
cgra: (but had plenty of peers to play with)
asciilifeform: afaik this doesn't make a behavioural diff, aside from the obv. fact of unreachability by fresh connections coming from outside
cgra: asciilifeform: right
asciilifeform still thinks 'cement' is the closest thing to Final Solution to 'fast sync new noad'
dulapbot: Logged on 2021-12-05 16:27:15 asciilifeform: ( to an extent you can get what historically folx were hoping to get from headerfirstism from 'cement'. but even that requires a bit of thought to get right. )
cgra: asciilifeform: i'm not proposing this as an initial sync, but for continuous operation, perhaps primarily because of the 'spam guard'
asciilifeform: right
cgra: asciilifeform: i mean, not ~only~ as an initial sync, does help both
cgra: i believe the spam guard can cause a stuck sync, for example, when all the peers send their new best block inv's to us too early, and now register that block as 'known by us', and won't respond with hash of that block anymore to our later getblocks requests
asciilifeform: would be also pretty great if all of this logic weren't part of a buggy pseudomultithreaded state machine with good helping of effectively ~random behaviour..
asciilifeform: is imho astonishing that it worx at all.
cgra: asciilifeform: genuinely a work of '(f)art'
whaack: new patch coming online...
whaack: !e view-height
trbexplorer: block_height: 720812
trbexplorer: mins_since_last_block: 13
whaack: !e view-tx 728 1
whaack: !e view-block 720812
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-25#1076246 I've no debt, and intend to keep it that way forever.
dulapbot: Logged on 2022-01-25 15:23:38 mats: oh right, i forgot, loans are haram
verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-01-25#1076293 I also try to have a better posture when typing, I try and fail to break regularly, and I've been taking vitamins. I prefer when I was younger, and didn't really need vitamins.
dulapbot: Logged on 2022-01-25 15:41:22 whaack: mats: i have no idea if what i did helped or if i'm even actually better vs. just having reduce symptoms, but i've been focusing on keeping an upright posture, taking collagen and magnesium supplements everyday with store-bought water, and doing exercise on the slackline