jurov: !w poll
watchglass: Polling 12 nodes...
watchglass: 205.134.172.27:8333 : Alive: (0.033s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284 (Operator: asciilifeform)
watchglass: 205.134.172.26:8333 : Alive: (0.082s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 108.31.170.3:8333 : (pool-108-31-170-3.washdc.fios.verizon.net) Alive: (0.048s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284 (Operator: asciilifeform)
watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.144s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 205.134.172.6:8333 : (172-6.core.ai.net) Alive: (0.157s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 208.94.240.42:8333 : Alive: (0.107s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 192.151.158.26:8333 : Alive: (0.182s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 143.202.160.10:8333 : Alive: (0.223s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 213.109.238.156:8333 : Alive: (0.398s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 188.121.168.69:8333 : (rev-188-121-168-69.radiolan.sk) Alive: (0.311s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.623s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=638284
watchglass: 176.9.59.199:8333 : Busy? (No answer in 20 sec.) (Operator: jurov)
whaack: It may be worth listing python2.7 as a required dependency here http://thebitcoin.foundation/trb-howto.html . I had trouble building boost with python 2.6.6 http://ztkfg.com/2020/07/building-trb-on-centos-69-notes-on-a-few-gotchas/
asciilifeform: whaack: recall that jfw's variant removes 'rotor' build system (i.e. the item which auto-built all deps, incl. the correct gcc, boost & deps, etc.) afaik it is meant to use on his linux, where all of these items are already present.
jurov: asciilifeform: but foundation's build does use rotor
asciilifeform: aha
asciilifeform: unless i misread, tho, whaack was using jfw's variant.
whaack: yes, I was using jfw's variant
asciilifeform: ( which, if built on anything other than musltronic linux, will give you a 'bad old days' dynamically linked bin, with unknown dysfunctions, depending on yer linux )
jurov: For the record, I should mention that rotor needs glibc <2.28 on build system because it moved some include files which break the bootstraping of m4.
asciilifeform: jurov: indeed it aint a 100% pill against arbitrarily broken build env. may have other sharp edges also. but does give reproducible bin when builds -- which a rotorless trb on arbitrary linuxen will not.
whaack: Argh, I see. So perhaps it is a mistake to build trb w/ jfw's patch unless you are on a known environment.
asciilifeform: whaack: it was specifically meant for use on his distro, is my understanding.
asciilifeform: whaack: if you want his other patches but aint using his linux, you will have to manually fork.
whaack: asciilifeform: I understand that jfw's patches are made for his linux (or atleast a "sane" environment) but I'm not sure what you mean about having to manually fork.
jurov: asciilifeform: but the link http://ztkfg.com/2020/07/building-trb-on-centos-69-notes-on-a-few-gotchas/ implies jfw did in fact use rotor, he built it on centos 6.9
jurov: where do you get the notion he ran bitcoind make directly on some musl system?
jurov: whaack: thx for headsup, i'll dig some centos machine and try it
jurov: ahh asciilifeform meant this: http://fixpoint.welshcomputing.com/2020/build-system-overhaul-for-bitcoind/
jurov: it says explicitly "it makes both development and deployment much less painful, with a sane starting system as the price of admission."
jurov: and centos isn't quite there
asciilifeform: right
asciilifeform: removing rotor is Right Thing ~if and only if~ you already have a working musltronic linux.
asciilifeform: (there's 0 point to it, simply burns cpu, if you already have the static libs, correct gcc, etc)
asciilifeform: whaack: while yer tuned in, on tangent : it aint practical to 'make trb watch ALL addrs' as enumerated set. (would need a rather different data structure) but you don't actually need to , for block explorer. afaik all of the traditional ones were made simply via cutting up blocks and throwing into ordinary db -- for humans reading via www, it is generally fast
snsabot: Logged on 2020-05-15 14:28:07 asciilifeform: guaranteed o(1) access.
asciilifeform: enuff
asciilifeform: whaack: fwiw i posted a while ago example block & tx parser in ada. imho illustrates the format adequately. for other langs there are examples on various www.
asciilifeform: ( note however that my example does not do anything with scripts , other than storing'em )
whaack: asciilifeform: digesting the above, thanks
whaack: asciilifeform: Alright, let me see if I understand. (I haven't digested the ADA code, not knowing any ADA myself.) To make a block explorer, as the term is generally used, one needs to provide a way to lookup all txn's related to an address and that address's UTXO set, in O(1) or at least <2s time. One should also be able to give a txid (which is the same as a tx hash, right?) and receive the
whaack: details of that txn. These two O(1) lookups are the block explorer's two main jobs. To do this, you essentially need to create new index's on trb's db. Had satoshi coded the thing sanely this may have been a real easy task / something that comes shipped with trb, but unfortunately that is not the case. There are two ways to go about creating the index for tx hash -> txn data. You could have
whaack: another db monitoring trb. This db copies all of the txn data it sees in trb (we'll say 100 blocks deep to ignore reorgs) and creates an index on txn hash. Or you could potentially save space by not copying the txn data, and instead storing a map of (txn hash -> location-of-txn-data-in-trb) . And I understand you describe a plan for this last strategy in your above link.
asciilifeform: whaack: almost anything you try, is likely to work 9000x better in erry way than the original -- where he used lotsa variably-lengthed data structures, with variably-long fields, and stored'em verbatim
asciilifeform: whaack: the reason i picked 'store compact/fixed-length indices to trb-style representations' is that it was intended to work as replacement for bdb in trb. (given as other nodes demand the traditional format, you gotta be able to obtain representation of arbitrary items in orig. form)
asciilifeform: whereas if yer baking a www block-viewer thing, you can simply parse the orig. blocks and keep in whatever format you like (e.g. traditional sqlistic db)
whaack: asciilifeform: right, that's my plan, using jfw's gbw-node as my starting point
asciilifeform not read enuff of jfw's published item to know whether it contains 100% of the req'd pieces
asciilifeform: iirc he had a generator which produced trb-style 'classical' tx, but not arbitrary eater for existing tx
asciilifeform: whaack: in what are you writing yer proggy ?
whaack: asciilifeform: it is still being planned, but i believe it will be a fork of gbw-node so python2.7
shinohai: http://logs.nosuchlabs.com/log/therealbitcoin/2020-07-08#1000809 <<< not sure how I missed this, but neato asciilifeform
snsabot: Logged on 2020-07-08 12:08:31 asciilifeform: whaack: fwiw i posted a while ago example block & tx parser in ada. imho illustrates the format adequately. for other langs there are examples on various www.
asciilifeform: shinohai: was a '17 item, orig. published as tarball
asciilifeform: shinohai: originally it ended up blocked on a gnarly gnat problem, since solved.