#asciilifeform | 2022-02-18

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079658 << does 'level-by-level' here also mean 'branch-by-branch'? ie. can validate transactions one by one, as they stream from peer, if provided with enough related higher-level merkle hashes

dulapbot: Logged on 2022-02-17 13:37:43 asciilifeform: would've been entirely possib. to send the header, then the 1st level of merkelisms, then n+1st, etc.

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079659 << asciilifeform prolly agrees that, strictly speaking, block hash is derived from the 80-byte block header, while the 'merkle root' hash is ~embedded~ in the same header. but i don't grasp how would merkleism allow tx reordering without the merkle root changing

dulapbot: Logged on 2022-02-17 13:38:52 asciilifeform: (for n00bz: block hash is a 'merkle tree', i.e. permits reordering tx and get same hash)

cgra: see CBlock::BuildMerkleTree() here, which returns the merkle root hash

asciilifeform: cgra: level by level.

cgra: example: lv 3: tx hashes A B C D E; lv 2: merkle hashes AB CD EE; lv 1: merkle hashes ABCD EEEE; lv 0, merkle root: ABCDEEEE.

asciilifeform: asciilifeform oughta have said concretely -- obv. cannot reorder arbitrarily; but possible in principle to send by level.

cgra: asciilifeform: how do txes divide into levels?

cgra: can only see branch division

asciilifeform: come to think of it, cgra is right, can't send by level

asciilifeform not sure where got this notion

asciilifeform: !w poll

watchglass: Polling 14 nodes...

watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.081s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=723899

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=723899

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=723899

watchglass: 205.134.172.27:8333 : Alive: (0.145s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899 (Operator: asciilifeform)

watchglass: 71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.155s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899 (Operator: asciilifeform)

watchglass: 205.134.172.28:8333 : Alive: (0.154s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=723899 (Operator: whaack)

watchglass: 208.94.240.42:8333 : Alive: (0.204s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899

watchglass: 54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.259s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=723899

watchglass: 94.176.238.102:8333 : (2ppf.s.time4vps.cloud) Alive: (0.308s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723044

watchglass: 82.79.58.192:8333 : (static-82-79-58-192.rdsnet.ro) Alive: (0.328s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899

watchglass: 103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.654s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899

watchglass: 75.106.222.93:8333 : Alive: (0.477s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=723899

watchglass: 143.202.160.10:8333 : Busy? (No answer in 100 sec.)

watchglass: 205.134.172.26:8333 : Busy? (No answer in 100 sec.)

cgra: asciilifeform: why are gapped cements supported in your draft patch?

cgra: a minor point: for consistent only-public-methods-with-lock, would move cs_cement from currentEntry() to getExpected()

asciilifeform: cgra: for experiments where a .. b blox cemented, b+1 ... c not, c+1 .. d -- are

asciilifeform: cgra: currententry aint even needed, lotsa gnarl in there, will clean up

asciilifeform: not even convinced the lock is needed

cgra: asciilifeform: right (re lock likely unnecessary as cement now is)

asciilifeform: cgra: other thing is, orig. asciilifeform wrote this where only supported cements of 0..n. then realized that often enuff will want to use cement to 'catch up' a mostly-synced noad, and 0 .. max is pretty heavy (>50MB atm) , would like to be able to cement a .. b for arbitrary a<b height.

asciilifeform: cgra: hypothetically w/out lock could get inconsistent behaviour if loading cement takes place while cement's 'verify' or 'expectcement' happening

cgra refrains from further lock comments until has pressed item to look at

asciilifeform: there's at least 1 place where asciilifeform forgot to remove a lock and it gets invoked from inside same. surprisingly worx.

asciilifeform: (evidently trb's locks lib makes this a noop)

asciilifeform: testbed at height 221646 just nao.

cgra: asciilifeform: cement segment makes sense for catch-up yeah, not yet come up with a case where gapped beneficial

asciilifeform: cgra: prolly oughta eggog on multiple cements that aint consecutive.

asciilifeform: (conceivably sumbody may want to load cement in batches, esp. if e.g. we post'em in batches on tbf. but these oughta be consecutive.)

cgra: asciilifeform: trb's locks are recursive, yeah. sätöshi's been doing nested same-locks too

cgra: ("sätös", btw, in finnish, means "a haphazard, poorly designed or built creation")

asciilifeform: ha.

asciilifeform: cgra: was thinking re parallelism -- can't think of how to even attempt it on the current turd, what with its single db cursor, ocean of locks, and the fact that block n might contain tx where inputs in anywhere 0 .. n-1

cgra: asciilifeform: the only part i was thinking the parallelization for, was that now it alternates between downloading and verifying, these don't overlap other than perhaps worth a 64k tcp buffer

asciilifeform: cgra: where decent (e.g. 1g/s) pipe on both sides, block downloads in 8msec. so not 100% certain this is worth the moving parts/complexity

cgra: asciilifeform: yeah, true. depends on whether can lock-in to a 100kb/sec node as well a 1gb/sec node, depending on the phase of the moon

asciilifeform: cgra: interestingly, as-written it seems to gravitate to pulling blox from fastest (at given time) peer

asciilifeform: given as how that tends to be the one who responds 1st

asciilifeform: an entirely accidental win

asciilifeform: w/out any purposeful coad to this end

cgra: asciilifeform: what signs of gravitation you've seen? not just the first node it started with, and still going with the same?

asciilifeform: cgra: seems to switch erry coupla hrs, but at no point thus far 'stuck with slow'

asciilifeform: granted this'll need plenty moar empirical test to say that in fact never happens

cgra: right

asciilifeform: so far all asciilifeform knows is that the sync is carrying on at ~same pace as does w/ 'eatblock' from disk in earlier experiments.

asciilifeform: however obv. these so far are the 'lighter' blox

asciilifeform does suspect that 'fastest' peer in fact delivers the asked block 1st, to the degree that the 'ask' in fact takes place in parallel

asciilifeform: ... and consequently moar likely to be the 1 who answers the ~next~ ask, etc

asciilifeform: the peculiar thing is that asciilifeform sees virtually no dupes from the lagging peers

cgra: asks, more or less, schedule with 2min intervals

cgra: no dupes prolly cuz always download and verification from first giver succeeded under 2min

jonsykkel: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-18#1079851 << cud be. havent looked into trb and its diseases too much yet, maybe cementing changes the equation, dunno. if run into wall ill rip out either db or hdd

dulapbot: Logged on 2022-02-18 08:46:58 cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079773 << mech hdd with the bdbmay prove unfeasible, while still an interesting experiment

asciilifeform: jonsykkel: cement dun affect the verification time of valid blox, but does cut down on the cycles wasted on unwanted ones during sync

jonsykkel: from where does all the unwanted blox come from anyway?

asciilifeform: jonsykkel: inv responses

asciilifeform: normally you end up getdataing for whatever new items yer noad saw in incoming inv's

asciilifeform: in hopes that 1 of'em is 'next' block

jonsykkel: would think these invs are requested based on blokheight+1 or smth

jonsykkel: barely looked at code tho so dunno how it works

asciilifeform: jonsykkel: there's no involvement of blockheight in inv's or getdata's

asciilifeform: i.e. you get sent a block , and noad attempts to fit it as the next one, and succeeds or not

jonsykkel: how does peers know wat blok to send then?

asciilifeform: (in ancient pre-trb, incoming blocks were buffered, asciilifeform abolished this, see the 'orphanage' vpatches / discussions)

asciilifeform: jonsykkel: see the coad, there are 2 ways of requesting blox

asciilifeform must bbl

jonsykkel: ye ill read relevant parts

asciilifeform: ... 230k.

asciilifeform: cgra: was thinking, anuther (if ugly) form of 'parallel' would be to load'em 1st, ~then~ verify sequentially. imho not req'd tho, would likely save very little time on a reasonably-connected box

cgra: asciilifeform: prolly just gotta take time to see experimentally/think through staring at the code, whether significantly still could lock-in to a slomo-peer

asciilifeform: aha

cgra: hmm, i remember as if some trb peer used to be a slow-link one. could try making cement-mode start off with such a peer, and see if makes operator sad or not

asciilifeform: cgra: i'ma leave mine going for at least coupla wks or until fully syncs

asciilifeform: cgra: did try it w/ buncha randomly-picked peers, did not manage to get it stuck thus far

asciilifeform: prolly worth moar deliberate efforts if folx have time ( asciilifeform sadly does not atm )

cgra: asciilifeform: did you hit a slow node, or not sure?

cgra: i mean, random shots could've all hit on fast nodes, unless otherwise clearly didn't

asciilifeform: absolutely not sure

asciilifeform: if anyone has a 'known slow' noad -- plox to write in.

asciilifeform: cgra et al : revised draft vpatch for cement.

asciilifeform: (on top of yest.'s)

asciilifeform: currently running on testbed in place of previous. ~same logic, slightly less gnarl as discussed in cgra's earlier thrd.

asciilifeform: ... 250k+

asciilifeform: ( ~23 hrs since start )

crtdaydreams: In more http fear mongering.

crtdaydreams: wish I never ``upgraded''

asciilifeform: crtdaydreams: so don't upgrade it, wat.

whaack: do upgrade, by downdating, don't up_date_

whaack: upgrade<->update synonym is ~psyop

asciilifeform: wb whaack

asciilifeform: whaack: can do e.g. this, when you've the cycles.

dulapbot: Logged on 2022-02-16 00:31:42 whaack: so it'd be mighty nice to get the cement vpatch running in the near future

asciilifeform testbed at 263+k, no stalls thus far

crtdaydreams: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-18#1079958 << ``rolling release'' distro. a la void lincox

dulapbot: Logged on 2022-02-18 20:25:38 asciilifeform: crtdaydreams: so don't upgrade it, wat.

crtdaydreams: so not much choice. want to do LFS but dun want dep. hell.

crtdaydreams: dunno if /g/entoo is what it was cracked up to be, only installed it once and couldn't wrap my head around the package manager

signpost: gentoo isn't measured by whether you bothered to learn how to use it, lol

signpost: also inspect your wants; they're tangled in contradictory directions

verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079735 I appreciate the praise.

dulapbot: Logged on 2022-02-17 21:39:04 jonsykkel: verisimilitude: red now, good shit

verisimilitude: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079736 I wanted to demonstrate the idea well, and so went with a design that minimized the number of tables and composition rules. This served me well when I realized I could turn the same tables into a parser, whereas with this design it's not so clear. The point is to minimize the code in favor of data.

dulapbot: Logged on 2022-02-17 21:39:12 jonsykkel: tho i fail to see why u didnt just do smth greek like http://zzz.st/up/NeHlDMls/

verisimilitude: I didn't review my words so carefully. I loathe parsing.

verisimilitude: Still, I turned the same tables into the inverse translator, say.

verisimilitude: This style of programming is particularly good at handling edge cases; compare it favorably to Common Lisp's EQL methods.

verisimilitude: Also, my program minimizes the total computation: there are divisions by one hundred and ten, and a modulo by fifty.

← 2022-02-17 | 2022-02-19 → ↑