| 14:40 |
whaack |
!e view-height |
| 14:40 |
trbexplorer |
block_height: 720763 |
| 14:40 |
trbexplorer |
mins_since_last_block: 7 |
| 14:48 |
asciilifeform |
$ticker btc usd |
| 14:48 |
asciilifeform |
ah lol bot awol |
| 14:48 |
asciilifeform |
!w poll |
| 14:48 |
watchglass |
Polling 14 nodes... |
| 14:48 |
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 |
| 14:48 |
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 |
| 14:48 |
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 |
| 14:48 |
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) |
| 14:48 |
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 |
| 14:48 |
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) |
| 14:48 |
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) |
| 14:48 |
watchglass |
208.94.240.42:8333 : Alive: (0.204s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764 |
| 14:48 |
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 |
| 14:49 |
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 |
| 14:49 |
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 |
| 14:49 |
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 |
| 14:49 |
watchglass |
75.106.222.93:8333 : Alive: (0.439s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=720764 |
| 14:50 |
watchglass |
143.202.160.10:8333 : Busy? (No answer in 100 sec.) |
| |
~ 3 hours 19 minutes ~ |
| 18:10 |
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) |
| |
↖ |
| 18:10 |
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~. |
| 18:10 |
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. |
| 18:10 |
jonsykkel |
i think idea of prog internally doing "identity == chain" for l2+ is good |
| 18:10 |
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 |
| |
↖ |
| 18:11 |
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 |
| 18:11 |
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 |
| 18:11 |
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. |
| |
↖ |
| 18:11 |
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 |
| |
~ 15 minutes ~ |
| 18:27 |
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: |
| |
↖ |
| 18:27 |
dulapbot |
Logged on 2021-12-06 10:00:57 cgra: asciilifeform: i'll just make a blog piece of this too, sometime soon(ish) |
| 18:27 |
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 |
| 18:27 |
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 |
| 18:28 |
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()" |
| 18:28 |
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 |
| 18:28 |
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. |
| 18:29 |
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 |
| |
↖ |
| 18:35 |
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 |
| 18:35 |
asciilifeform |
wb jonsykkel & cgra ! |
| 18:36 |
jonsykkel |
ty ty |
| 18:39 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077011 << correct |
| 18:39 |
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) |
| 18:40 |
asciilifeform |
jonsykkel: except, the 'i am bobart' will point to 'i am bob' (in a designated chain field) |
| 18:40 |
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. |
| |
↖ |
| 18:40 |
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 |
| 18:41 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2022-01-28#1077018 << 'rule 1' of network protocols -- it sumthing can happen, it ~will~ happen |
| 18:41 |
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. |
| 18:41 |
asciilifeform |
esp. if that 'sumthing' breaks you. |
| 18:41 |
asciilifeform |
esp. if it breaks you w/out being readily attributable to the breaker. |
| 18:43 |
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 |
| |
↖ |
| 18:43 |
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 |
| 18:43 |
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 |
| 18:44 |
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. |
| 18:44 |
asciilifeform |
jonsykkel: asciilifeform's pov is that if hearsay can't be decacophonized, it is largely useless |
| 18:46 |
jonsykkel |
right, but would still be decacophonized when reading, confusion only occurs if try address collided ppls |
| 18:47 |
jonsykkel |
autoreplacing handles in messages text carries own uglyness |
| 18:47 |
asciilifeform |
the focus there is to get folx to quit colliding asap. 1 way or anuther. |
| 18:48 |
* |
asciilifeform agrees that substituting handles in msg text is an ugh |
| 18:48 |
jonsykkel |
indeed |
| 18:49 |
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. |
| 18:49 |
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 |
| 18:51 |
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 |
| 18:51 |
dulapbot |
Logged on 2022-01-26 19:16:32 asciilifeform: this is similar to the 'trb in cave' problem. |
| 18:51 |
asciilifeform |
cgra: prb's 'headers 1st' approach makes it trivial |
| 18:52 |
asciilifeform |
(to do it to a freshly-built noad, that is) |
| 18:53 |
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 |
| 18:53 |
cgra |
asciilifeform: imo this isn't headers-firstism, why do you think so? |
| 18:54 |
* |
asciilifeform may be missing sumthing |
| 18:54 |
cgra |
isn't any more headers-firstism than the getblocks/inv is -- first asking for hashes, then receiving a bunch of them in response |
| 18:56 |
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? |
| 18:57 |
asciilifeform |
http://btc.yt/lxr/satoshi/source/src/main.cpp#2045 |
| 18:58 |
cgra |
afaik not many concrete blocks get thrown around, while plenty inv adverts flying |
| 18:58 |
* |
asciilifeform will have to reread the sores & come back to this thrd |
| 18:59 |
* |
asciilifeform not touched trb gearbox in a depressingly long time |
| 19:00 |
cgra |
asciilifeform: i suspect you've forgotten something about the 'inv' mechanism |
| 19:00 |
cgra |
(otoh, my head being solid bone not ruled out as a possibility either) |
| 19:00 |
asciilifeform |
no, i remember that it exists, but also iirc most of the blox received by trb aint from getdata per se |
| 19:00 |
asciilifeform |
i.e. it never getdata'd for'em from a previously-recv'd inv |
| 19:01 |
cgra |
asciilifeform: my test node was always behind a nat... |
| 19:01 |
cgra |
(but had plenty of peers to play with) |
| 19:03 |
asciilifeform |
afaik this doesn't make a behavioural diff, aside from the obv. fact of unreachability by fresh connections coming from outside |
| 19:04 |
cgra |
asciilifeform: right |
| 19:06 |
* |
asciilifeform still thinks 'cement' is the closest thing to Final Solution to 'fast sync new noad' |
| 19:06 |
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. ) |
| 19:07 |
cgra |
asciilifeform: i'm not proposing this as an initial sync, but for continuous operation, perhaps primarily because of the 'spam guard' |
| 19:07 |
asciilifeform |
right |
| 19:07 |
cgra |
asciilifeform: i mean, not ~only~ as an initial sync, does help both |
| 19:10 |
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 |
| 19:13 |
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.. |
| 19:14 |
asciilifeform |
is imho astonishing that it worx at all. |
| 19:14 |
cgra |
asciilifeform: genuinely a work of '(f)art' |
| |
~ 3 hours 6 minutes ~ |
| 22:21 |
whaack |
new patch coming online... |
| |
~ 23 minutes ~ |
| 22:44 |
whaack |
!e view-height |
| 22:44 |
trbexplorer |
block_height: 720812 |
| 22:44 |
trbexplorer |
mins_since_last_block: 13 |
| 22:44 |
whaack |
!e view-tx 728 1 |
| 22:45 |
trbexplorer |
http://paste.deedbot.org/?id=nbkS 1 of 1 |
| 22:45 |
whaack |
!e view-block 720812 |
| 22:45 |
trbexplorer |
http://paste.deedbot.org/?id=dfpf 1 of 1 |