log☇︎
700+ entries in 0.063s
a111: Logged on 2019-07-16 12:29 girlattorney: asciilifeform that's something interesting: once (not now, a couple of days ago) i was able to get to the general height, thanks to a couple of restart that allowed me to get those last blocks (it seems that when TRB starts, always download instantly 10-15 blocks). Basically when it was at the network height (synced) it was also connecting to core
asciilifeform: girlattorney: which is why you want to advertise at least 1 of your nodes , in your fleet, publicly, to other trb folx
asciilifeform: girlattorney: the gold standard for 'is my trb node publicly reachable?' is : to connect to it from another trb node.
girlattorney: i hope so, cause i was starting to thinking that TRB getting stuck fetching the last blocks could because the local address
girlattorney: behind a nat there is no way to tell TRB to ignore the 1st addrLocalHost
girlattorney: when i ran TRB in a box with a public routable address, there also was the double addrLocalHost, but always with the same public routable address
girlattorney: yes, i'm able to connect externally, my question is: can i tell TRB to not announce my local address?
asciilifeform: for 'adult' trb node, you will want to route public ip to it
asciilifeform: no need to cross compile unless you're building for something too small to run gcc itself ( and chances are it won't run trb , if so small , as with 'pogo' )
asciilifeform: girlattorney: mod6's build system ( based on asciilifeform's earlier 2015 'rotor' (see logs) ) builds first a frozen-in-amber gcc & friends, ~then~ the depds (db etc) , ~then~ trb per se
asciilifeform: girlattorney: trb is more like kalashnikov than television set. i.e. can be made 'user friendly' only to a point.
asciilifeform: trb btw still retains the ancient mechanism where 'try to avoid connecting to >1 peer on same 24block'
asciilifeform: mp_en_viaje: this is easy to do, only rub is that there are already 3 ( 4? ) trb nodes at piz, all on 1 ip block, and sharing a quite modest pipe.
a111: 4 results for "cement trb", http://btcbase.org/log-search?q=cement%20trb
asciilifeform: !#s cement trb
asciilifeform: girlattorney: it is already rare for trb people to do 'cold start', usually they 'light smoke' from existing
asciilifeform: trb, unlike prb, does not accept blocks 'on credit' (i.e. ones for whom the antecedent block is not yet on the disk) ☟︎☟︎
asciilifeform: ~95% of cpu cycles (as measured by asciilifeform in '16) of trb, is spend waiting for disk.
mp_en_viaje: girlattorney, so wait, is this delayed trb running on a vps or on its own colocated box ?
asciilifeform: that's the gold standard, yes, physical box, w/ ssd, running strictly trb, and on serious (preferably industrial, but top-of-class residential fiber also worx) pipe
asciilifeform: girlattorney: trb on public toilet 'vps' hosting is generally a nonstarter
asciilifeform: girlattorney: in my experience, trb (with my 'aggression' patch) syncs from 0 in roughly 3wks, on a decent (fiber) pipe. however, last did this yr+ ago, and unsurprisingly the interval will only ever increase, as the chain gets heavier (on avg., grows 1000000 bytes erry 10min, recall)
asciilifeform: girlattorney: i attempted to bake exactly such in '14 , but the iron wasn't there yet ( we got a large supply of certain arm box, but only 256MB of physical mem, and only ~then~ found that without a total rewrite, trb cannot be sat down in 256M or even 1G )
girlattorney: in a near future i think that it could have sense to have a TRB marketplace, where you can buy your ready-to-deploy box
asciilifeform: girlattorney: trb is its own backup, think about it
asciilifeform: girlattorney: in my flagship trb box, i found that 1T samsung ('standard', rather than 'pro', not yet tested 'pro' series) ssd runs for just short of 2yrs prior to write cycle exhaustion
mp_en_viaje: trb does not need (and does not much benefit) from swapping.
asciilifeform: disable swap; i have found that on 2GB+ boxen trb , despite heavy mem fragging, will not overrun 2GB
asciilifeform: girlattorney: trb (for time being) retains the classical 'ask peers for new peers' mechanism, so unless you hand-curate the peers (most trb folx do) you will inevitably connect to garbage nodes at the statistically expected rate
asciilifeform: if you were looking at linux disk stats, you may have box with swappism enabled. (or do you actually have a 8TB drive, that trb somehow filled ?!)
girlattorney: asciilifeform that's something interesting: once (not now, a couple of days ago) i was able to get to the general height, thanks to a couple of restart that allowed me to get those last blocks (it seems that when TRB starts, always download instantly 10-15 blocks). Basically when it was at the network height (synced) it was also connecting to core ☟︎
a111: Logged on 2019-07-16 12:07 girlattorney: if it could interest, from 0 to block 584k, TRB has written to disk almost 8 TB
a111: Logged on 2019-07-16 11:27 girlattorney: if it's just an ip + port it can be a "fake" node. What interest me is the fact that TRB seems to ignore the nodes with a user agent different than "therealbitcoin.org:0.8.88.88". I even tried to just have a "addnode=*corenode" and in some odd way it finds a way to communicate only with the TRB nodes
asciilifeform: http://btcbase.org/log/2019-07-16#1922523 << trb doesn't ignore, the (prb-powered) 'blockchain sites' ignore. ☝︎
girlattorney: it's an arm board with a sata slot, so i can attach a 1TB ssd and let TRB running for a couple of years
girlattorney: mp_en_viaje i know a little bash, i used to compile bitcoin core until knowing TRB and my project would be to compile TRB for an arm board, to eat less energy than my PC (the ARM board would be an hardkernel Odroid hc1)
deedbot: asciilifeform rated girlattorney 1 << trb n00b / new blood
asciilifeform: !!rate girlattorney 1 trb n00b / new blood
a111: Logged on 2019-07-16 10:44 girlattorney: hi, thanks for voice, i'm here to ask about trb. Installed it on my PC, and after 28 days almost synced. Then it happens the following: when TRB is almost at the current height (as now, 585,647), it stays back a few blocks, like now that is at 585640, and just cannot catch the latests blocks
mp_en_viaje: there's probably some room for optimization wrt disk usage ; but that's rather wating for the more comprehensive trb-fs thing
girlattorney: if it could interest, from 0 to block 584k, TRB has written to disk almost 8 TB ☟︎
girlattorney: if it's just an ip + port it can be a "fake" node. What interest me is the fact that TRB seems to ignore the nodes with a user agent different than "therealbitcoin.org:0.8.88.88". I even tried to just have a "addnode=*corenode" and in some odd way it finds a way to communicate only with the TRB nodes ☟︎
mp_en_viaje: well, for you there's then no answer to the "how do trb nodes get blocks" question you had.
girlattorney: ok i'm gonna wait. I'm just interested in what happens with TRB nodes: with a public site that list public nodes (with 8333 port exposed, site is bitnodes dot something), i checked and it says that there are 8 TRB nodes.
girlattorney: btw i noticed that trb only connects and fetch blocks from other trbs, so i don't get what happens with the other core nodes
mp_en_viaje: (which would be the "latest" trb, though obviously v-trees are a little different from traditional notions of latestness)
girlattorney: latest trb (currently available on thebitcoin.foundation) installed on debian 8
mp_en_viaje: girlattorney, which trb / how did you install it ?
girlattorney: hi, thanks for voice, i'm here to ask about trb. Installed it on my PC, and after 28 days almost synced. Then it happens the following: when TRB is almost at the current height (as now, 585,647), it stays back a few blocks, like now that is at 585640, and just cannot catch the latests blocks ☟︎
asciilifeform found that reasonable trb noad more or less requires adult fiber. set it up one time in a commercial pad where 'commercial cable', would sit for months and not sync
a111: Logged on 2017-11-19 05:19 lobbes: Currently going down the headless-browser path ben_vulpes suggested. Looking into phantomjs atm, which seems like it could do the job. I have an old craptop I'm thinking of using as the proverbial 'public toilet' to house it on. (This is the same craptop I was planning to put a trb node on. I put a spanking-new ssd in there but then realized that the ethernet dun work anymore; wifi only. May be a good use for the thing to just be a turd server in
mircea_popescu: or alternatively, there's all sorta greatness, phf has a perfectly workable code metadiscussion system on btcbase, jurov had a ver yworkable one for earlier trb work and so fucking on.
mircea_popescu: that also wouldn't be a trb server, practically speaking.\
trinque: mircea_popescu: end up with a working trb-running server more quickly than I do today
asciilifeform: corollary to this q : how would a 'trb ebuild' differ from the trb vtree as it stands ?
mircea_popescu: trinque, let's go at this a different path. what would you even do with a trb ebuild ?
asciilifeform: i have not tried it with megafauna like trb
asciilifeform: but e.g. trb , pretty heavy, 0 autoconf (in the proggy per se, that is; there is some in the deps, however)
mod6: I still consider them "in-progress", but will forward what I have along to you here by Monday. (I wanted to get these ones built before the trb one - which I'm just starting on now.)
asciilifeform: on top of this, buncha other '19 material, in various stages of publication ( e.g. the mips ; massive pile of bolix material, O(1) adatronic db replacement for trb , not published yet; and coupla other ) ☝︎
asciilifeform: ever tried to read bellard's 'qemu' ? i dunno if decade would be enough to eat it, trb-style, even if did nuffin else.
asciilifeform: ( re eulora, as i currently understand diana_coman's main work atm is an excavation, similar to trb circa '15, of heathen coad )
a111: Logged on 2019-05-28 22:16 mp_en_viaje: asciilifeform, thinkign about it, there's just no way to have a proper trb without the rainbows. and yes it'd be 32 gb, but so what. the point stands, there is a minimal bitcoin box.
asciilifeform: depends what means 'modern linux'. e.g. asciilifeform's trb 'buildroot' weighed under 5MB.
mp_en_viaje: " and dbs -- trb ALSO should keep track and sum the hash weights.
mp_en_viaje: since we're discussing "trb should
a111: Logged on 2018-10-22 22:37 asciilifeform: mircea_popescu: unrelated to anyffing: i have a tentative thing that eats a http://btcbase.org/log/2018-10-20#1864354 and gives trb option of replacing 'checkpoints' with it ( i.e. on boot, tests all already-stored blox against it, and if any blox in the tape are not yet present, then it requests & accepts them and only them, 1 at a time ). do we want this for field use ? (if so i can put on conveyor for cleanup)
mp_en_viaje: what i'm sayng here is, that a trb w/o the rainbow tables is shipped defective, like a car without wheels or w/e, toys without batteries.
mp_en_viaje: for other uses, just not load it in memory. but trb gotta ship with them.
mp_en_viaje: asciilifeform, thinkign about it, there's just no way to have a proper trb without the rainbows. and yes it'd be 32 gb, but so what. the point stands, there is a minimal bitcoin box. ☟︎
asciilifeform: still gotta add, that trb bringup takes weeks not because the set weighs 100TB ( as erryone already knows, it's below 300GB atm ) but cuz the sync mechanism is rather sad
asciilifeform: mp_en_viaje: iirc this is 1st recorded such case ( d00d took the sweat to build trb, note that there ain't a '4lusers' binariola package or anyffin of the kind) but then went and planted it on a lolhost
BingoBoingo: The TRB 3-6 week sync (CPU and disk bound) is a strictly linear, no exceptions to verification affair
diana_coman: nocredit: for that matter if running own trb is too big a pain/expense, I suppose you might be better served by getting in the wot and using deedbot's wallet for that matter.
nocredit: correct, I appreciate TRB as it removes the bloat. But 3 weeks to sync is really a pain
asciilifeform: incidentally, there's a vacant rk, and if customer chooses to use the available sata snake and a 1tb ssd, he can trb. BingoBoingo plox to add this to the advertised list.
asciilifeform: diana_coman: colo people can run trb, or for that matter anythign else
diana_coman: for paying customers who may want to run trb, what?
asciilifeform: diana_coman: for trb ?! it already has 3 iirc trb nodes
asciilifeform: nocredit: the reason your log consists 80+% of 'discarded block' is that trb deliberately does NOT hold on to a received block unless it matches the litmus for possibly being the immediately next block in the chain. this is deliberate, and i personally wrote this patch.
asciilifeform: nocredit: approx 3 weeks, if you're syncing from trb nodes via -addnode .
nocredit: hi, thanks for the voice. Basically trb (with aggressive patch) simply is too slow to sync, and i'm using a VULTR vps with 6 cores and 16GB of ram. For too slow i mean that after 1 week is just at block height 300k
diana_coman: nocredit says he needs support with trb so let's here
a111: Logged on 2019-05-17 17:10 asciilifeform: http://btcbase.org/log/2019-05-17#1914364 << this is quite similar to the direct ancestor of v , jurov's trb mailing list system .
feedbot: http://blog.mod6.net/2019/05/building-trb-on-cuntoo-part-1/ << mod6's Blog -- Building TRB on Cuntoo: Part 1
trinque: I'd love to see a trb ebuild come of this mod6
asciilifeform: mod6: plox to detail ( e.g. if on musltronic cuntoo, why needs 'rotor' system ? it existed only to build musltronic gcc 1st, and ~then~ trb, on heathen envirs , recall )
mod6: Evenin'. I've built trb on cuntoo with ave1's 20180924 tools, with rotor only. Quick test shows pulls connects, pulls blocks.
asciilifeform: http://btcbase.org/log/2019-05-17#1914364 << this is quite similar to the direct ancestor of v , jurov's trb mailing list system . ☝︎☟︎
asciilifeform: and result is ~useless board, no canhaz trb in 1GB
asciilifeform: bvt: you'd have to connect a real disk to have a useful trb, but otherwise i can't see why not
bvt: i have a http://archive.is/EUW9n item at home, with kernel from some arm64 distro and pizarro rockchip rootfs, but i never got time properly setup this device (plan was, run trb node)
asciilifeform: 'geshi' actually weighs moar than trb.
asciilifeform: that 1 , i dun even think about much, given trb dun suffer from it
asciilifeform: diana_coman, spyked : at this pt , 5 yrs in, i'm satisfied that i understand how ~trb~ pushes tx; problem lies in the zoo of ??? 'nodes', what do ~they~ do with it.
a111: Logged on 2019-04-03 08:43 spyked: upstack, re. tx propagation voodoo: the good part about this is that it got me into reading trb code and logs re bitcoin and trb. will be back to feedbotworks, but I'll say, this has been instructive
asciilifeform: diana_coman: must admit, currently i have massive hole of mystery where 'how and where does trb tx propagage' oughta be. is why last autumn i sat down & wrote (most of) a fairly gnarly proggy to try & map out node zoology & mempool dynamics. but sadly on hold presently, not enuff hands
spyked: upstack, re. tx propagation voodoo: the good part about this is that it got me into reading trb code and logs re bitcoin and trb. will be back to feedbotworks, but I'll say, this has been instructive ☟︎
a111: Logged on 2019-04-02 11:03 spyked: noob question re bitcoin: is there an expected time for tx propagation to peers' mempools? details: I'm running a fully synced trb node, connected to trusted republican nodes using -addnode. I've sent 2 txen using sendtoaddress ~3hrs ago and none of them are on e.g. blockchain.info so far
spyked: noob question re bitcoin: is there an expected time for tx propagation to peers' mempools? details: I'm running a fully synced trb node, connected to trusted republican nodes using -addnode. I've sent 2 txen using sendtoaddress ~3hrs ago and none of them are on e.g. blockchain.info so far ☟︎