asciilifeformtrinqueagriculturalsupremacyossasepiaspykedpizarrotrilema
8h 34m20d 58m12h 30m2h 5m2h 10m5d 7h 54m2h 10m



1000 entries found in trilema for 'f:ifeform f:escu trb' :

mircea_popescu: now, as to the putative customer approach : i dun specifically want to make a new os for every single app we come up with. i'd like to make one and be done with it, such that minigame can use it, trb can use it, everyone can fucking use it.
mircea_popescu: the original trb work suffered from a massive aglomeration of -ev workforce.
mircea_popescu: i expect the principal problem of trb attempt was horrid management.
asciilifeform: same goes for the trb users. (wai they not 'went over with comb' ~before~ ? it's what signing means. 'i understand what i'm signing.' )
asciilifeform: ( unrelatedly, noticed this morning that (for 1st time?) all the trb noades known to asciilifeform , are properly synced )
asciilifeform: the trb's been keeping up better than any i've operated to date, but would be unscientific entirely to say that 3d of it mean anyffin.
asciilifeform: ( there's diana_coman , ersatz-dulap hosting http://logs.nosuchlabs.com/log + bot, and a trb . )
asciilifeform: unrelatedly : seems 213.109.238.156 is new trb noad, in kiev ? who built? seems to actually work, a++
asciilifeform: mp_en_viaje: if after all you dun need a znc , leave the thing switched on, i'ma reformat when next test pilot volunteers, until then will run trb , i want proper test of trb perf on apu1. but if you decide you want a znc, su znc ; znc -c will run promptistic configurator. then reboot, and you'll have it.
asciilifeform: mp_en_viaje: item is general-purpose pilot box, plz feel free to mutilate any way you like. the trb is a copy of 'zoolag', can replace w/ own favourite build, or switch off, etc. there is a nearly full chain. znc is set to smoketest knobs, if using , must reconfig.
asciilifeform: mp_en_viaje: prepared, however, box, if still interested. runs trb and znc ( the latter w/ default config, presently logs into fleanode as 'pilotplant' and joins #a , can fill in yerself or switch off by removing the crontab ) on boot.
asciilifeform: for mp_en_viaja, i have the choice of 1) standard rk, cum znc 2) apu1 w/ 1gb samsung ssd, cum znc, and in fact prepared trb on it also.
asciilifeform: for a novel 'trbi' is entirely uninteresting what or how did fucking openssl.
asciilifeform: but again this is only interesting if one's building a '100% trb-compat' in e.g. ada.
asciilifeform: is only relevant to people who want to build trb-compat. mechanism from ground.
asciilifeform: mod6: importantly, tho, most of this horror aint relevant to 'trbi'
asciilifeform: mod6: annotation of trb is a+++ Right Thing imho.
asciilifeform: mod6: imho it is only because we have trb, that other meaningful work has what to breathe.
asciilifeform: imho these are the fundamentals, without which all other adventures pertaining to trb (e.g. propaganda) are meaningless.
asciilifeform: nao asciilifeform is no one in tbf. but will be sad if it comes to be the case that there is no tbf to fund emplacements of noades, curation of the ref. trb (incl. mod6's very fine build system) .
asciilifeform: iirc at least 1 had a trb noad going on rk .
asciilifeform: incidentally network is down to 3, maybe 4, working trb noades, such as are known to asciilifeform .
asciilifeform: diana_coman: he appears to know about asciilifeform's orig. fumigated gentoo .
asciilifeform: diana_coman: in recent years, asciilifeform's experience was 'trb-grade box is ~100 $ / mo just about anywhere' , so consistent with this.
asciilifeform: diana_coman: outta curiosity, were the btc receiver addrs they genned, trb-compat ?
asciilifeform: 49 € / mo. for e.g. trb box, aint bad, imho.
asciilifeform: already in the 'pogo' experiment we had a working 32bit arm trb. so i expect it is doable with existing toolchain for 32-under-64.
asciilifeform: dorion: at some pt we'll definitely want a properly 64bit trb on arm, so can use >4GB. thing is, currently there appears to be no arm64 box on the market that actually has >4GB.
asciilifeform: not even any kind of new plague. mircea_popescu recall how we had to cut a buncha gifs etc outta pre-trb to bake the genesis.
asciilifeform: trinque: and then you gotta delete these ? what if you want the resulting link to remain clickable ?
asciilifeform: BingoBoingo: nginx was an old heathen attempt to 'trb treatment' of apache by 'cut all the pieces i dun use' -- of 1 particular user.
asciilifeform: for thread-completeness -- if anyone has a trb that aint in my addnode ( the piz nodes -- already are in ) and would like it included -- plox to comment.
asciilifeform: anyone else running a trb w/ 'who-gave' -- invited to publish theirs .
asciilifeform: btw re trb : BingoBoingo et al : http://nosuchlabs.com/pub/trb/whogave_10_20_2018-8_31_2019.txt << almost 1y of 'who-gave' blox log .
asciilifeform: to formalize : asciilifeform's current hypothesis is that there is a thin 'tube' of trb-compat. nodes b/w pekin & trb orchestra. responsible for 100% of new blox.
asciilifeform: BingoBoingo: think, this is elementary. as soon as they issue a 'bloomism' or similar cmd to a trb node -- they get malleus'd. and yet we still get blox in realtime for 6-7 months at a stretch.
asciilifeform: before considering any such horror, rly oughta fix propagation b/w trb !!
asciilifeform: the correct frequency with which situation 'trb node a is at height H, its peer trb node b is at H-k, for hour+' oughta happen, is ~never~
asciilifeform: BingoBoingo: yest.'s episode cemented in my head the insufficiency of my orig. 'aggression' patch. i strongly suspect The Right Thing is some variant of ben's. with the orig., node eats 5-10 blox when connects to trb peers on restart, then the connections stable and gets nomoar for hours. whereas on ea. restart, in facts gets the 5-10.
asciilifeform: in re trb -- zoolag ~still~ chewing on a block (perhaps the genuine ..450, perhaps not) even nao.
asciilifeform: re further trb lulz : 24.93.104.14 spams liquishit blox at ~gb/s
asciilifeform: ( and, recall, when trb is verifying , all net processing grinds to a halt )
asciilifeform: BingoBoingo: quite likely, if you were to try an' reprocess that turd into a trb-edible block, you will end with a perma-wedged node.
asciilifeform: BingoBoingo: and indeed no one in known trb world seems to have ...450 just yet.
asciilifeform: girlattorney: trying to get trb box for 20 is rather like trying to get luxury automobile for 1000
asciilifeform: in most places, a trb-grade box leases for equiv. of maybe 100 $ (usa) .
asciilifeform: girlattorney: re colo -- talk with diana_coman , who has been surveying various colos. ( piz is pretty packed in re trb, has no fewer than 3 operating nodes . and really these benefit from being dispersed geographically, rather than concentrated in 1-2 cages ! )
asciilifeform: girlattorney: the major weak point is propagation from miners, who are living in own parallel chinese universe and between whom and trb there is a thick layer of garbage.
asciilifeform: girlattorney: most folks who know how to operate trb, have at least 1 public and some # of unadvertised nodes.
asciilifeform: the more properly working trb nodes there are -- the less payoff to anyone for monkeying with their connectivity. at present in fact i do not know how many there are. not erryone bothers to advertise .
asciilifeform: girlattorney: observe that there is no attempt at authenticating peers in the existing trb. you could easily be connecting to washington's node when thinking yer connecting to e.g. mp_en_viaje's. at one time i published an experimental patch where can route to people you personally know via ssh pipes, but currently not in use anywhere afaik.
asciilifeform: girlattorney: were you able to make your trb node ?
asciilifeform: trinque: re clocks, at one time mircea_popescu suggested to use trb block as clock. but imho is of very limited use as clock, cuz not guaranteed to advance in any given interval.
asciilifeform: diana_coman: this aint even the most egregious example, there's trb patches ~by asciilifeform~ that have since been reground that iirc i haven't signed yet
asciilifeform: mircea_popescu: ftr my own measurements are wildly variant, i suspect the 3 ( 4? ) trb nodes are bursting and eating pipe
asciilifeform: to where retire ssd? if still 'worx', e.g. trb node. lappies. if end of life ? stoke furnace. ( see mircea_popescu's piece with furnace. )
asciilifeform: it is even possible that the pipe is to blame, i.e. the measurement is 'random' depending on how congested the pipe at piz on acct of e.g. the multiple trb noads sitting there
asciilifeform: i dun recall hearing any serious barf. ( and i think somebody still has a trb noad there )
asciilifeform: !q s f:ifeform f:escu trb
asciilifeform: of erry 20 folx that ask re 'my trb stopped at block B', 19 problem is impatience.
asciilifeform: 0 to do with trb.
asciilifeform: !Q later tell mod6 prolly oughta change that webchat link at trborg to go to your castle
asciilifeform: i/o, however, is only ~4x slower than host's, so in fact one ~could~ run e.g. trb on it.
asciilifeform: 'golden age' of ben in re trb etc was when was in own shop .
asciilifeform: ( it was only then that even devised the algo, during thread w/ mp_en_viaje re 'trbi' )
asciilifeform: mp_en_viaje: frustratingly, i have the 'trbfs'. but grrrr gnat bugola
asciilifeform: http://btcbase.org/log/2019-07-19#1923625 << was a sort of cheat tho, the genesis did not actually include bdb etc ~textually~ . so maintained illusion of 'trb is this 300kB of shitoshi'
asciilifeform: ( for n00bz -- trb was 'tank w/out treads' for, iirc, 1st 6+ months, until this )
asciilifeform: at one pt i thought same re asciilifeform vs. trb . ( then mp_en_viaje unwedged me , he had bdb notes , '14 )
asciilifeform: certainly has NOT 'stood in place since 2015' tho. i would not want to use the trb of '15 in preference to the current.
asciilifeform: thing is, trb is imho mature in re 'knobs' , the time nao is to ~cut~, slice an' dice an' replace with adaistic prosthetics
asciilifeform: in fact, recall how trb 'chicken' genesis was a hand-cranked recipe, cuz had to delete binary gif turds etc and vtron of the time could not autodigest such deletion
asciilifeform: the other side of the medal, is that a trb node spends only small portion of its life in initial sync.
asciilifeform: the 'reject peers sending garbage' mechanism is also mine. trb did not always have it. i submitted it for inclusion to mod6's flagship after determining that it results in substantially improved performance across the board (i.e. peers sending bloomism are, statistically, an unlikely source of the-next-block)
asciilifeform: i personally removed this nonsense, as 1 of the opening shots of trb story.
asciilifeform: girlattorney: 'discard excess' in trb algo is ANYTHING received when its antecedent is absent.
asciilifeform: girlattorney: simple logical inference (there's a number of publicly advertised trb nodes; most of'em agree with heathendom re the height) points to : no, not 'only with themselves' dunnit.
asciilifeform: girlattorney: will still be banned by any working trb node, on acct of sending nonclassical protocol cmds (bloom filter garbage etc)
asciilifeform: girlattorney: post plz your last half MB or so of trb log
asciilifeform: the other variant is to do a la trb, genesis e.g. 3.70.16 (arbitrary, happens to be what i had around during 1st test) and ~then~ cut, a la trb. but it is gargantuan , would make trb genesis look microscopic in comparison, viewing the genesis patch in e.g. phf's viewer will prolly crash most www browser..
asciilifeform: mp_en_viaje: doesn't require hand-hexing, since trb actually stores all blox, simply needs re-walk trigger
asciilifeform: http://btcbase.org/log/2019-07-16#1922900 << imho it is foolish to take down a trb noad (i.e. allow it to fall behind) simply to copy the db. the best backup for a trb noad is a 2nd, 3rd,... node.
asciilifeform: there's a vacant rk, prolly adequate for anything short of trb node
asciilifeform: but -- cheap. and 2G ram/GB nic/sata/etc. potentially useful, for, as original poster , trb.
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.
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.
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.
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 )
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
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 ?!)
asciilifeform: http://btcbase.org/log/2019-07-16#1922523 << trb doesn't ignore, the (prb-powered) 'blockchain sites' ignore.
asciilifeform: !!rate girlattorney 1 trb n00b / new blood
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
asciilifeform would rather roll out gossipd, trbi, sane comp irons, etc. ~with~ participation of mp_en_viaje , and with working isp, than w/out. but may have to without, apparently.
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.\
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)
asciilifeform: http://btcbase.org/log/2019-06-22#1919166 << trinque sweated out a draft cuntoo, which sadly i have not had chance to test in anger. i have a physical box that is destined for it , when get chance, and also will be porting it to the sim-mips, ditto. but i promised to mircea_popescu not to undertake any elaborate works until ffa suitable for 'discard gpg' and extension to other (gossipd, trbi, what else is waiting on it) paths
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 )
asciilifeform: depends what means 'modern linux'. e.g. asciilifeform's trb 'buildroot' weighed under 5MB.
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
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
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 .
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 )
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
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.
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
asciilifeform: http://btcbase.org/log/2019-03-30#1906193 << interestingly, at 139.2 kloc , still 1 of the heaviest proggies in civilized use; vs, e.g., trb ( http://btcbase.org/log/2018-11-29#1876053 ) ; but lighter than koch gpg ( if minus autoconf, http://btcbase.org/log/2017-07-08#1680705 ) or linux kern.
asciilifeform: trinque: any idea whether there is a www-navigable map of these anywhere ? ( a la ye olde trb flow graph 'wish item' ) ?
asciilifeform: it's shovel work, and necessary shovel work, just like maintaining trb.
asciilifeform: incl. trb , gnat, FG.
asciilifeform: it's not clear to me that the congenital defects are fixable ( hence the various 'trbi' threads etc )
asciilifeform: hanbot: orig 'v' was an asciilifeform torture room item, but it was other folx who made it actually useful ( mircea_popescu -- conceived a philosophical foundation for it, conceptually; ben_vulpes -- documented; mod6 et al -- reimplemented , and filled missing pheature holes ; trb users -- battlefield-tested; phf -- keccakized; etc )
asciilifeform: http://btcbase.org/log/2019-02-24#1899032 << when 'v' started 'living' outside of domain of strictly trb, asciilifeform did eventually write 'open problems' piece re subj, http://www.loper-os.org/?p=1545
asciilifeform: http://btcbase.org/log/2019-02-24#1899025 << imho trb ml contains massive record of ' asciilifeform's initial failed attempts at v ' : the sequence of 'determine flow with bare hands' pre-v patches. ( signed, too )
asciilifeform: http://btcbase.org/log/2019-02-24#1899016 << more boringly, item was born from trb work ( and specifically jurov's mailing list mechanism , with enforcement of patch signatures ) , i.e. 'hand-cranked v', so ended up on the trb ml.
asciilifeform: ( trb vgenesis released slightly ~prior~ to 1st vtron per se, recall )
asciilifeform: nursing old gnat aint optional, currently, just like nursing trb aint optional
asciilifeform: granted. sorta why i said 'it's a trb'
asciilifeform sees linux kernel, gcc, ftr, as 'life support' item, rather like trb -- worth freezing and maintaining until proper replacement, but not really items with a serious future
asciilifeform: trb-capable box, btw, i have one going .
asciilifeform: ( e.g. asciilifeform was quite surprised when found that trb and ALL deps built cleanly & functioned on static musl )
asciilifeform: re 'e', i can't picture what'd move anyone with two neurons to rub together to maintain a glibc, that'd be rather like starting a trb from prb 12 (or what is current one)
mircea_popescu: yes, no glibc was in fact a preference, and we got it out, of trb, of eulora, etc. no argument there.
asciilifeform: this was a 2015 find. after which asciilifeform immediately proceeded to get glibc the hell out of trb.
asciilifeform: ( and asciilifeform -- trb ) etc
asciilifeform: 4MB aint enuff to e.g. trb inside. tho 1 could rsa in it.
asciilifeform: http://btcbase.org/log/2019-02-14#1896276 << notably ye olde trb-on-pogo asciilifeform recipe ran off initramfs
asciilifeform: ( consider how long took to clean , to reasonable level of non-sepsis, trb -- a 200x smaller product )
mircea_popescu: but in any case, can start talking of a much better trb sitting.
asciilifeform: mircea_popescu: recall the 9000 headaches of folx who tried to build pre-rotor trb ? asciilifeform did not resort to 'and now run this 4 hour script that builds a gcc, and then builds with it a gcc, and ~then~ builds deps, and ~then~ trb' just to make life moar interesting.
asciilifeform: http://btcbase.org/log/2019-02-09#1893996 << d00d ripped off trb, and even wrote a piece of yarn to go with it where 'he stole great jewel from dumb orcs'. today hangs with kako. seems to have sinological / eastern 'learnings' wank - leanings.
asciilifeform: ( and muchly superior to how asciilifeform did trb's 'chicken' genesis, where was stuck giving it as hand-cranked recipe on acct of the vdiff of the period being unable to describe deletion of binturds )
asciilifeform: ( would have to make sure that the trb deps are baked into cuntoo , naturally -- the stock bdb oughta be the 1 in trb, etc )
asciilifeform: lets you have e.g. the trb indexer thing, as ordinary array, etc
asciilifeform: ( mass-wise, apache is considerably closer to the mass of e.g. gcc, than trb ; but on other hand seems to need less massage as it is, as mircea_popescu fond of pointing out, it largely worx )
asciilifeform: e.g. trb , grew from acorn of tarball supplied by mircea_popescu in '14.
asciilifeform: s/bdb/trb in above
asciilifeform: http://btcbase.org/log/2019-01-22#1889099 << i daren't to 'do something about it' until properly understood the problem. sorta like didnt dare to attempt trb in 2013, or ffa in 2015, etc
asciilifeform: this is well studied in trb, but applies elsewhere
asciilifeform: and ( again like trb ) it dies disgracefully at the boundary of capacity,
asciilifeform: mircea_popescu: thing is roughly like trb - can throw iron at it until it eats the desired reqs/sec without shitting self. but, just as in trb, it's a barbaric/empirical ritual, quite impossible to say 'on napkin' how much cpu will yield what # of what kB pg served /sec w.out falling
asciilifeform: *experimental trb, err
mircea_popescu: meanwhile in news : http://btcbase.org/log/2019-01-19#1888338 << mystery solved. trb uses bdb for block indexing ; the index had an incorrect lobe affecting some blocks ; whenever someone asked for one of those blocks, bdb died and trb never returned.
asciilifeform: mircea_popescu: sounds potentially interesting. ( if you publish outputs, plox to not forget to say what pressing that trb was made from )
asciilifeform: this was back when asciilifeform had nfi why trb wouldn't statically link, not yet found drepper's 'gifts'
asciilifeform: shinohai: neato. what didja do re trb ?
mircea_popescu: in other arcana : i have here a copy of trb that has died a mysterious death on dec 31st. the process itself hasn't returned, ps aux lists it as expected, however the last time it touched any files was two weeks ago, nor does a call to getinfo ever return.
asciilifeform: and ftr i'm surely doomed to run into diana_coman's puzzler myself, when i go to write a threaded proggy (e.g. adaized trb)
mircea_popescu: in fact it's 100% trb toy/"training muppet"
asciilifeform: exactly like trb then
asciilifeform: it's a trb-like item
asciilifeform: trb has , what, 3x the # of patches, so it'll take you 30m at most.
asciilifeform: it's what i'ma do to trb after i solve the mmap thing.
asciilifeform: loox like only the trb www moved, ml was on separate box, still needs moving.
mircea_popescu: yeah, sane db will be major boon to trb (also not news, discussed as such since original "devs are idiots" times)
asciilifeform: will note, even with the heap fragging nonsense, current trb has quite reasonable ram footprint; e.g. i run 'zoolag' on a 2GB box, and never manually reset aside from when deploying patch (coupla times in past yr)
asciilifeform: ( old trb dun 'suck' blox, except on boot; it waits to be fed )
asciilifeform: ( not only luck of ~the network~, but , perversely, the sadder the box , moar often it gets reset, the better pre-aggr trb worked.. )
mircea_popescu: speaking of penalties : i dusted off ancient trb (pre agression), just for curiosity. turns out it sucks ~1 block/minute in the 450k range (ie, catches up with a year's chain per month, sorta thing).
asciilifeform: mats: i assume you had most recent mainline trb (i.e. with 'aggression' ) ?
mircea_popescu: diana_coman http://ossasepia.com/2018/12/19/a-week-in-tmsr-26-november-2-december-2018/#selection-105.764-105.817 << actually, a major bomb was dropped there, wherein long standing trb-immunity was revoked.
asciilifeform: http://btcbase.org/log/2018-12-03#1877916 << to date we've had both types of regrind ( e.g. diana_coman reground 'mpi' into 1 genesis, for use in smg ; ffa on other hand had a 'history-preserving' regrind , http://www.loper-os.org/?p=2743 ; and iirc mod6 is baking a 'history' regrind for trb ; diana_coman had 'history' regrind for eucrypt; and possibly i missed somebody in this list )
asciilifeform: exactly like trb.
mircea_popescu: (this so neatly mirrors ye trb/prb discussions it bleeds)
asciilifeform: unrelatedly, to whom does trb noad 69.197.146.42 belong ?? it's been wedged for year+
asciilifeform: ( for comparison: e.g. http://btcbase.org/log/2017-07-08#1680705 ; or, current trb is ~22k loc, ~not~ incl. the dep balls )
asciilifeform: near as i can tell, threatened to do ~sumthing or other~ with wallet trb... in 2017
asciilifeform: trb, emacs ( might be hard cookie, but gotta ) , various engineering tools
asciilifeform: mircea_popescu: trb dun use any 'wwwism' from ssl, only the ecc numerics, so i expect just about any extant version will link and run. the rub is how it'd behave in unexplored corner cases, as in the der sig affair
mircea_popescu: wouldn't it be ~nice~ if you used some kind of sane naming convention ? trb.adding-ffa.alf ? something ?
mircea_popescu: bug free, fast enough, etc. not like we're pressed by anything here, not like trb ceases to exist while we cut its guts open and so on.
mircea_popescu: and yes, ffa majorily useful, and no, not necessarily against writing for it. but there may be a timing issue (trb that takes > minute to check block is useless)
mircea_popescu: ideally, with as little re-factoring of trb components as possible.
mircea_popescu: re-write what trb uses.
asciilifeform: the one where http://therealbitcoin.org/trb-howto.html : 0x12) Get http://deedbot.org/deed-422651-4.txt : name it 'openssl-1.0.1g.tar.gz.asc'
asciilifeform: mircea_popescu: so idea here is 1st to cut the classic tar to 'what used in trb' ?
asciilifeform: mircea_popescu's old observation re the dacia air filter still holds tho, potentially replacing the hairball in trb with a 100% correct numeric set, will result in a forkable.
mircea_popescu: but yes, as far as trb work is concerned, a) taking off the bulidroot process because b) move it to cuntoo and also c) replace ssl dependency with one file, <1k loc are the priorities.
asciilifeform: if mircea_popescu gives signal that we're fucking done with the old flintlock pistols, then i'ma start welding on ffa in trb as soon as the former is battlefield-ready.
asciilifeform: well yes, eventually all of trb oughta turn into 'our correct coad'
mircea_popescu: why import ssl into trb anyway, makes 0 sense.
asciilifeform: mircea_popescu: afaik only in trb is needed
asciilifeform: ( ideally we'd simply keep the logic demanded by trb and burn the rest. but dunno that anyone has the free hands for this presently )
asciilifeform: mircea_popescu: there's an 'openbsd-branded' item, 'libressl', quite similar to the hairball carried along in trb but weighing slightly less
asciilifeform: if said bugs affect trb logic, than it oughta be in trb asap ; if they do not, then not clear to me why better
asciilifeform: for that matter, why does cuntoo need to include own sslism, afaik the only proggy that hard-depends on having one is trb
asciilifeform: trinque: now that i think about it -- what was the logic for including the alt-ssl in cuntoo, vs trb's frozen thing ?
asciilifeform: ( given a musltronic cuntoo, the 'rotor'-descended buildroot process for trb is theoretically redundant )
asciilifeform: will also be interesting to see if trb can sit down on trinque's libressl thing, instead of the frozen ancient openssl it currently goes with
asciilifeform: they junkyardwars'd together a working ottoman-style org system ought of sumthing like '80s su -- sorta like we trb from prb etc
asciilifeform: jurov: can haz it again plox ? it was pretty great, i used it in all of my trb work
asciilifeform: ( recall the ancient trb flow chart thread )
asciilifeform: jurov i was gonna link to your lxr ( which i've used 9000 times in all trb work ) as example of why ^ , but it seems to be down
asciilifeform: mod6 & other trb folx ^^
asciilifeform: bvt: of course it does, trb is 100% static-linked and has plenty
asciilifeform: ( there's 200+ col. lines in trb )
asciilifeform: they're already in, e.g., trb. but was thinking, perhaps folx will eventually stop, cuz it's a headache and to fix it is not in any sense expensive imho.
asciilifeform: early trb , for instance. i had nfi how to cure the db locks thing until mircea_popescu supplied the pill.
asciilifeform: btw, BingoBoingo , re waaay upstack -- trb 'throws bastards' from the simple reason that it doesn't keep track of peer heights, and ~always~ retransmits any block that it gets and happily welds to longchain
asciilifeform: mircea_popescu was not fond of 'cement', because sees (correctly) that it is a kludge. but imho given the single-threaded classical trb, it or something like it, is necessary
asciilifeform: current flagship trb cannot be replayed 'from genesis', but can be from 168000, per http://btcbase.org/patches/genesis#L3542 .
asciilifeform: speaking moar generally of replays -- because of the idjit method shitoshi used for block-gettin', where 1 peer can ~monopolize connection for just about as long as he wants -- a stock trb node , syncing from empty, is in fact in a position to be fed just about arbitrarily long replay chain. which is why my interest in sane checkpoint variant.
asciilifeform: tldr : the shitcoin people are in fact pretending to compatibility with ordinary btc protocol; even going as far as using unchanged version strings, and backdated block timestamps ( of course trb rejects the liquishit in O(1) , but it is entertaining )
asciilifeform: http://btcbase.org/log/2018-10-23#1865502 >> as promised >> http://nosuchlabs.com/pub/trb/fuckwads_in.pcap ( filtered , for convenience: only incoming crapola )
asciilifeform: wtf this idjit is doing connecting to trb noadez, is anybody's guess.
asciilifeform: i have not observed this on trb to date, but it is precisely the q i was posing, whether can happen ( i.e. reorg logic fails ) in some possible alignment of planets.
asciilifeform: afaik to date trb demonstrably did Right Thing on reorg of arity 6 ( july '15 incident )
asciilifeform: i definitely watched a 60 blox reorg, but this was in pre- trb era
asciilifeform: mircea_popescu: observed on a trb node concretely ?
asciilifeform: afaik this is not a test that has actually happened in trb history ( longest naturally-occurring reorg since trb first saw use in the battlefield was, iirc, 8 blox or so ? )
asciilifeform: seems that he wanted to test whether trb's miner component actually worked.
asciilifeform: $item pertains strictly to current-day trb
asciilifeform: i can't picture wanting any old cpp crapola in trbi in general
mircea_popescu: certainly. in general speaking, trbi will prolly not use any of the current trb/prb legacy common code
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)
asciilifeform: billymg: ( trb, for instance, doesn't even support dns lookup. i cut it with own hands; eats bare ip. )
asciilifeform: ( for the impatient : http://nosuchlabs.com/pub/trb/snap_546400.txt )
asciilifeform: already turned up a buncha oddities re noades -- for instance, just about errybody not-trb still sends out gavinalert (with 'key compromised!' message. wai -- i have nfi )
asciilifeform: ( in prelim experiment thus far, virtually errything that aint a known trb noad, appears to show one or more obv symptoms )
asciilifeform: in unrelated noose, mod6 et al : loox like trb doesn't remove banned peers from its addr table ! i.e. offers their addrs up to others, as if they were proper noades!! i never noticed this previously, it had to wait to be found empirically. really oughta be fixed, and pretty simple patch.
asciilifeform: this line of thought was prompted by my 'trb observatory', which has uncovered a number of 'mpb'-style nodes, i.e. trb-like but not presenting 'modern' vers and therefore invisible from heathen www indices
asciilifeform: phf: i was aiming for 3 basic things : 1) recursively getaddr entire reachable btc net, perhaps erry hour or so 2) find trb-compat (i.e. 'services' == 1 ) non-pseudos (i.e. if i pull block hash out of a hat, he quickly gives correct block) and eventually 3) get inv's and monitor tx propagations.
asciilifeform: worx ok with trb. but heathens do all kinds of weird things, throw up various garbage in place of e.g. getaddr answer
mircea_popescu: which is why all the "oh noes advertise ip" bla bla machinery is always a sign of idiocy on the part of "designer". trbi needs "ip backflow" like i need power rangers in my living room.
asciilifeform: it's a 2edged blade, as it would be a great temptation to 'light client' idjits to parasitize on trb. but would make for easy litmus.
asciilifeform: btw trb could in principle be made entirely distinguishable, if we were to permit asking for a ~tx~ in 'inv' command ( currently prohibited , because prb nuked indexing , but could be brought into trb with no ill effect aside from some cpu cost )
asciilifeform: re upstack -- as it happens, 'trb-compat' is pretty easy to distinguish mechanically -- anybody who has 'services' field != 1, aint trb-compat.
asciilifeform: individual display only of trb-compat folx.
asciilifeform: speaking of trb, i dusted off an old conveyor item, phuctor-like www proggy that maps out noadez ( you give it ips, and it connects to'em, then issues 'version' and 'getaddr', and builds a graph )
asciilifeform: lol, could even describe e.g. trb this way
asciilifeform: Mocky: 'aggressive' trb vs regular, is just about 'night and day'. i also have ben_vulpes's 'super aggression' item lined up for test.
asciilifeform: mircea_popescu: keccak is exactly the right pill for trbi, and iirc mircea_popescu was actually 1st to point this out, yrs ago
asciilifeform: Mocky: keep in mind that 'aggressive' trb syncs in (pessimistically) 2-3 weeks. so not much point in throwing around whole balls of blox.
asciilifeform: ( all you need is that little bash , and a reasonably recent trb )
asciilifeform: mod6, jurov : trb ml down ??
asciilifeform: diana_coman: erry so often i try an' search for some symptom that heathens know of trb etc., ~never found
mircea_popescu: phf we've all ranted about it at some time or another. needless to say replacement rsatron does not include idiotic half-baked state machines. much like trb-i doesn't include "accounts" nonsense.
asciilifeform: so nao moar apparent when friction at the interface of trbdom an' heathendom
asciilifeform: mircea_popescu: something to this; 'aggression' removed most (not all) instances of trb 'sitting with mouth open'
asciilifeform: meanwhile, in trb observatory... nuffin on surface. but! loox like all of trb planet stuck on 544911 ( heathens : 544928 )
asciilifeform: http://btcbase.org/log/2018-10-07#1859231 << will need to be instructed re basic trb doctrine
asciilifeform: meanwhile in trb observatory, http://nosuchlabs.com/pub/trb/10_5_6_7_ProcessBlock.txt
asciilifeform: diana_coman: i suspect idea was 'make him manually gpg --verify ... and then press by hand-gnupatch a la pre-v trb, better than signed tar'. but i'ma let phf clarify.
asciilifeform: rereading is great, but it isn't cost-free. if i sit down to reread trb , i'ma have to come back in a ~year
asciilifeform: meanwhile, in trb observatory... http://nosuchlabs.com/pub/trb/10_4_ProcessBlock.txt
asciilifeform: i'm quite reluctant to sink substantial moneys into heathen isps, for obv. reason. in that thread was thinking of 'cash and carry' modest item, strictly for moar-trb.
asciilifeform: ( possibly he even has it nao, i recall seeing a trb noad running from ru not too long ago )
asciilifeform: here is also where i must note that , while i'd like moar / moar-dispersed trb nodez, my time budget for trying to talk sense into remote orcs is quite limited atm
asciilifeform: 'Asciilifeform ran the experimental patch bringup in trb node zoolag' << bahahahawaaat
asciilifeform: aaand i'ma skip this morning's 'in trb observatory...' , it's a straight line of 'ACCEPTED' from known trb people
asciilifeform: sooo if anybody ( mircea_popescu ? diana_coman ? ) knows of some place that 1) isn't complete shit 2) doesn't have a trb noad living there yet -- plox to write in.
asciilifeform: i've been thinking i oughta conjure up moar trb nodez, but erry time i sit down and look to do it, end up thinking 'why give money to heathen derps'. but on other hand it dun do much good to put 9000 nodes all in pizarro. but to which heathen can give moneys without retching..
asciilifeform: meanwhile, in trb observatory, http://nosuchlabs.com/pub/trb/10_2_moar_ProcessBlock.txt << caught up..
asciilifeform: meanwhile, in the trb observatory, http://nosuchlabs.com/pub/trb/10_2_ProcessBlock.txt
asciilifeform: meanwhile in the trb observatory, http://p.bvulpes.com/pastes/cMfST/?raw=true << restarted zoolag, and confirms my earlier hypothesis -- 'bastards' from friendlies are simply when they throw their latest block blindly at each peer, without concern for who actually can eat it, and who cannot. shitoshi's shit protocol.
asciilifeform: i dun see why it would apply to trb tho, trb must have write or it cannot store blox.
mircea_popescu: http://btcbase.org/log/2018-10-01#1856377 << well, the way i read the 1-2-3-4 progression from above is that "it is focused but not limited to trb, supposed to outreach from it".
asciilifeform: as i observed just today and on 9000 occasions, even the simple thing of 'why can a trb node be 100 blox behind a fellow trb peer' is not yet licked
asciilifeform: fwiw i see my own work on trb, to date, as a ~defensive~ affair, i.e. to make whatever fixes req'd to keep the thing working precisely as it worked in 2009, in the face of the very real and continuing network rot / 9000 forms of active attack from heathendom to date
asciilifeform: way i see it, there's plenty of sharp edges left on good old trb, and any new work ought not to subtract from the very real remaining work of smoothing'em out.
asciilifeform: errything done to date, related to trb at least tangentially.
asciilifeform: ( and imho all of the people qualified to work on trbi, are already here, they dun need to see duck races to be persuaded to come... )
asciilifeform: i could even see an argument that the charter could permit 'trb-i' work under the flag of tbf. but that's as far as it goes, per my reading
asciilifeform: http://btcbase.org/log/2018-10-01#1856296 << i gotta admit that i dun see point in 'growth for growth's sake'. there was already prb 'foundation' for ~that~. tbf is for maintaining & improving (constructively! there's plenty of actual ills to cure, that dun reduce to 'not enuff heathen notoriety' ) trb.
asciilifeform doesn't use any fancy redirection-to-sys-logger for trb log, and doesn't intend to
asciilifeform: incidentally, does anyone remember wtf happened to the 'log timestamps' patch for trb ? who wrote it, and how come it never made it into the flagship tree ?
asciilifeform: and yea it's http://btcbase.org/patches/asciilifeform_aggressive_pushgetblocks/tree/bitcoin/src/main.cpp#L1362 that trb (and for that matter heathens, but fuck'em) doesn't respond to sanely.
asciilifeform: i'm pretty curious why a trb node is able to answer pfrom->PushGetBlocks(pindexBest, uint256(0)); with ANYTHING other than the immediately-missing next block, when it is known to have it.
asciilifeform: meanwhile, in trb observatory : http://nosuchlabs.com/pub/trb/10_1_ProcessBlock.txt << anatomy of a 'noad behind'. whole night zoolag fed nuffin but 'bastards', and incl. by friendlies, in continuation of http://btcbase.org/log/2018-10-01#1856264
mircea_popescu: i did not say "infect with trb".
asciilifeform: mircea_popescu: could've sworn we had the 'infect with trb' thread ..
asciilifeform: meanwhile in asciilifeform's trb observatory : http://p.bvulpes.com/pastes/SEy0g/?raw=true << 'bastards' emitted by ( among others ) friendlies. really is imho bug, trb ought not to send bastards to trb.
asciilifeform: as for others, i dun recall who is 149.56.19.79 but iirc also trb
asciilifeform: meanwhile, in other noose, http://btcbase.org/log/2018-09-29#1855579 >> http://nosuchlabs.com/pub/trb/9_30_ProcessBlock.txt << thus far .
asciilifeform: the 1 gotcha is that most trb-related items afaik constrained by scarcity of skilled l1 hands, not coin as such
asciilifeform: right nao we only have blox because chinese d00dz i've never heard of, and dun expect to, run ~trb-compat proggies. i've nfi if trb per se helps this state of affairs to continue, but for so long as it continues, oughta at least not interfere, imho.
asciilifeform: mircea_popescu: i dun propose to 'help' heathens somehow against will. but imho anyffig that in any way makes trb noad harder to stand up than strictly must -- yields terrain to enemy.
asciilifeform: ben_vulpes: as for 'premium' noad access, recall how the mircea_popescu 'trbi' thread was born. ( classical btc offers no sweet pill for how to reward node operators. any attempt to charge for 'gets mined faster' inevitably reduces to a game the miners can themselves win, cutting out middlemen )
asciilifeform: ben_vulpes: i see no gain from putting any obstacle in front of anyone, heathen, chinese, martian, good, evil, who wants to run trb .
asciilifeform: and yes at least 1 cretin 'stole' trb. what did it get him.
asciilifeform: can't replace the thing with 'republic only' trbi , not without some yet-unfathomed breakthrough, or, idk, if mircea_popescu takes over brazil, or, whoknows, catastrophic chernobyl that fully demolishes the classical btc net
asciilifeform: and yes if there were some magical way to get errybody who benefits from tbf and ergo working btc net, to put into the piggy, it'd be splendid, thing could fund even such things as flotillae of noads, or even trbi dev, etc, whoknows. but there is no magic. and it is a lucky thing that tbf in fact has the coin with which to do the bare minimum and host patches ( not on shitazon! jurov ! ) and handful of reliable nodes.
asciilifeform: http://btcbase.org/log/2018-09-30#1855796 << to the extent ( and it is a ~substantial~ extent ) that a healthy btc net relies on ~widely~ available sane client, incl yes even for miners, to limit in any way the distribution of trb src is imho catastrophically stupid idea.
asciilifeform: to date i haven't conceived of how to make trb into a subscription service ( my 1 attempt at the problem was the 'wires' item ) but this should not discourage others
asciilifeform: mircea_popescu: birth of trb was 100% powered by 'muscle-powered v' of gpg-signed patches, recall.
asciilifeform: without rock-solid trb, there is no bitcoin , at least not in any shape i'd particularly care to be connected with.
mircea_popescu: asciilifeform iirc it was kinda chartered with carte blanche, "do whatever, just do". the way history flew it worked out as a sort of "holder of trb project" pretty much yes.
asciilifeform: ( imho -- it's a preservation proj , to keep the thing going until trbi etc )
asciilifeform: and imho last thing trb needs is '9000 new idea'
asciilifeform: mod6: ftr i'm 100% satisfied with your work as trb chair
asciilifeform: mircea_popescu: currently not clear to me how there'd be less work if trb were 'mod6 proj' instaed of 'foundation'
asciilifeform: mircea_popescu: i disagree, btw, that 'epsilon', march-current is when the aggression thing was deployed & tested to exhaustion, and gave proper ~realtime block propagation for 1st time since trb birth
mircea_popescu: considering the rate of new work on trb approximates epsilon for the march-september interval, it seems to me entirely bullshit, this manufactured problem of "oh, we have no way to contribute because no working keccak".
mircea_popescu: the one useful thing here would be to get trb properly ground already.
asciilifeform: this experiment will work 9000x better once there's several trb folx other than asciilifeform doing it, cuz learning 'block x came from... this-here trb noad' dun tell me much, it'd be useful to know where ~he~ got it, etc
asciilifeform: ACHTUNG, panzers ! trb node zoolag will be down for approx 20min for experimental patch bringup, starting 5min from nao.
asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage'
asciilifeform: mircea_popescu: lol recall how we even ended up with v, ' asciilifeform : 'it is obvious!11 how to arrange trb patches' errybodyelse : 'nah' )
asciilifeform: once it ~does~ exist, and fully displaces the duct tape, then yes i'ma start regrinding other things , and i expect then mod6 -- trb, etc
asciilifeform: apparently diana_coman has been hand-cranking it, sorta like asciilifeform's 1st yr of trb pre-vtron
asciilifeform: mircea_popescu: trb is 100% sha currently
asciilifeform: wouldn't go this far; dunno about mircea_popescu , but i'm presently connected to fleanode, trb, etc via tcp
asciilifeform: would be neato imho if we could bring 2.6 back to life trb-style.
mircea_popescu: http://btcbase.org/log/2017-01-03#1595770 << alluded to in the more specified TRB.B/TRB.N prototype design.
mircea_popescu: http://btcbase.org/log-search?q=from%3Amircea+trb-i << interesting list, at that.
asciilifeform: iirc was one of the moar recent 'trb-i' mircea_popescu threads
mircea_popescu: but yes, this is the other half -- need to bake trb nodes that won't get insta-banned by wot-trb on sight because they spew garbage
mircea_popescu: http://btcbase.org/log/2018-09-24#1853601 << this seems so to me. how about we wot the trb, rather than iptables it.
asciilifeform: sanely-behaving nodes (both trb and hypothetical trb-compatible heathens, which exist, or we'd see 0 blox) ought to be able to find ~and keep~ each other company
asciilifeform: imho a trb node ought to only advertise addrs that either a) part of the manual --addnode set the node was brought up with , or b) actually supplied a correct block in the recent past
asciilifeform: mod6: i was thinking of trinque's idea : suppose trb closed all open pipes if it finds that $configurable hours (e.g. 3) have passed without new blox
asciilifeform: trinque: the crapola-gluetrap steadystate in trb is what i was trying to kill with 'wires' experiment
asciilifeform: it's a network problem, not a trb one.
asciilifeform: in mostly unrelated lulz, there are apparently noads who shove a couple 100 MB (!) of bastard blox into a connected trb, prior to the latter throwing the ban switch ( because of the idjit shitoshi networking routine, actual disconnect happens a good 10-20sec after ban )
asciilifeform: i can do it with shell ( as quoted from trb experiment list earlier ) easily enuff. but there is also the ~reader~ side, who wants to verify continuity.
asciilifeform: which complete kit oughta be able to follow the continuity of e.g. trb to day1.
asciilifeform: i put 9000 hrs into reading trb, i do not have these 9000 to do it exactly same again nao.
asciilifeform: mircea_popescu: canhaz link to 'hey folx, phf's vtron out of beta, let's regrind trb etc nao' ?
asciilifeform: hey mod6 , didja ever switch to new format in trb ?
asciilifeform: btw one of the items i have in the deep freezers, is a trb with block db ripped out, replaced with (half-finished, sadly) ada mmap thing
asciilifeform: ( trb still has )
asciilifeform: i suspect the time to snapshot and pour cement, trb style, approaches.
asciilifeform: i can see an argument for keeping a cut-down version (perhaps trb's) around on ~some~ boxen , simply for curl-for-fetching-heathen-www, but that's about it.
asciilifeform: like it or not, 'faberge egg' is not a good weapon. to which i'll add that imho trb only recently (with 'aggression') graduated from 'faberge' status, previously noad required regular babysitting, and i've found that this is no longer so
asciilifeform: observe that trb in fact worx pretty well, even though mircea_popescu did not lay cable.
asciilifeform: mircea_popescu: puzzler might have all sortsa interesting applications, possibly all the way to e.g. defraggings in a hypothetical trbi
asciilifeform: in other heathen lulz, https://archive.is/yUvwS << 2017-style shitfork , rebranded as a kind of faux-trb, 'Satoshi Vision' of... 'block size to 128 MB'
asciilifeform: mod6: hey, at least wolf d00d didn't go to whatevercon in vegas and present trb as own phd work or whatnot
asciilifeform: mod6: http://edgecase.net/articles/2017-11-25_edgecase_datafeed_article_21_2017-11-25_stjohn_piano_compiling_bitcoind_trb_054_on_debian_711/rotor.tar.gz.asc , http://edgecase.net/articles/2017-11-25_edgecase_datafeed_article_21_2017-11-25_stjohn_piano_compiling_bitcoind_trb_054_on_debian_711/programmable-versionstring.vpatch , buncha others
asciilifeform: dredged up d00d via script that digs for refs to trb in heathendom. turns out, he hosts mirror of trb patches ( they dun seem to be discussed in articles tho, near as i can see )
asciilifeform: mircea_popescu: threading in trb is exactly variant of ye olde http://btcbase.org/log/2016-01-21#1379603 -- it's there because idjit had nfi how to do nonblocking i/o
mircea_popescu: (yes, i'm using this to raise the army that'll surgerize trb, of course, of course)
asciilifeform: lol exactly like trb?!
asciilifeform: http://logs.minigame.biz/2018-08-14.log.html#t01:52:40 << incidentally asciilifeform coupla yrs ago made failed attempt to replace 'boost' in trb with cpp11isms. principle obstacle was that gcc 4.9x doesn't really have 100% working cpp11.
asciilifeform: Mocky: cpp proggy always rides on libc. witness trb, the orig experiment with musl here.
asciilifeform: trb noad is up again as of nao.
asciilifeform: iirc Funkenstein remains the unbeaten recordsman there ( operated, at least at 1 point, a shitfork based on cribbed trb )
asciilifeform looks at 'ircd-ratbox' , somewhat astonished at the mass, coupla MB of src (moar than, e.g., trb)
asciilifeform: shinohai: can relax, nobody is out to eat you, and yer a+++ trb tester, my rating for instance stands.
asciilifeform: !Q later tell phf plox to update stable trb tree in http://btcbase.org/patches from mod6's
asciilifeform: trb's footprint problems are 100% on account of heapism.
asciilifeform: for thread completeness i must add that there are items in the standard (i.e. 'tasks') that i do not use in ffa, but intend to make use of in future ( i.e. trbi ) , and may be let live.
asciilifeform: ( hence why asciilifeform did not say 'wtf, why you lot distribute binariola, why not post just src like trb ' )
asciilifeform: heathens are , as i currently understand, so unspeakably stupid that 'stealing fixed code' is not to date ever observed, they re-break as soon as they touch. ( any heathens stole trb for the shitfork warz, other than funkenstein ? )
asciilifeform: for all i know, somewhere there exists a d00d who tried to build e.g. trb on a vax. and thinks asciilifeform is idjit, because it dun go. how's that skin off my back.
mircea_popescu: http://btcbase.org/log/2018-07-15#1834748 << trb node is one of the few items that ~can't~ be backed up in the usual sense. because what you get if you just blindly copy is a shitup not a backup.
asciilifeform: a new node plugged directly in ( i.e. over lan ) to a working trb node, with 'aggression' should sync in week or 2.
asciilifeform: and whole concept of 'backing up trb' strikes me as wrongheaded -- the most effective backup is simply a 2nd node.
asciilifeform: shinohai: i've found that trb state can't be effectively backed up without stopping the node ( otherwise indices turn to barf . ) how do you do yours ? periodic stops ?
asciilifeform: http://btcbase.org/log/2018-07-14#1834457 << ftr this is a ~very~ Bad Idea . for instance , i do not know in what starvation-cheapo hoster brazilish put his node, but if it was aws he will find that he cannot connect to ~any of the l1 folx's trb nodes, most people ban aws ip range whole
asciilifeform: http://btcbase.org/log/2018-07-14#1834483 << just about anything with 2GB or more memory will work -- trb is not really cpu-bound . a 1TB disk will last you 3-5 yrs until fills. ideally ssd ( though the exact penalty from using mechanical disk is not yet known, see last night's thread ). if ssd -- i recommend samsung's, cheapo ssd typically burns after 1-2 yrs of trb wear.
asciilifeform: ( i vaguely suspect there exists even a 'herd immunity' of sorts, where aggressive trb helps other peers, of whatever config, stay in shape )
asciilifeform: afaik it doesn't auto-timestamp tho, iirc ben_vulpes , trinque , and possibly others, use linux system log to 'cheat' and get timestamps from trb
asciilifeform: i suggested it specifically to shinohai because he's apparently still experimenting with trb and afaik isn't tied up with anyffing else.
asciilifeform: ( point being, it may very well be feasible to run a reliable infrastructural trb noad on mech hdd. certainly worth test. )
asciilifeform: at any rate, the block processing delay was a kind of red herring, turned out that 'wait for rain to fall' was in fact the culprit in all ( known to asciilifeform ) cases of 'trb node won't stay in sync'
asciilifeform: notably , the patch started life as a general-purpose profiling of a whole buncha things in trb, but i ended up cutting out all but block timing, given as that was where something like 99% of ~active~ (i.e. as opposed to waiting for rain to fall, this was pre- aggression) cycles are spent
asciilifeform: diana_coman: reporting block r/w times currently requires pressing with the little patch that takes the times. ( it is not part of 'flagship' trb )
asciilifeform: i expect that soon n00b will be able to revv up a trb box simply by making use of trinque's builder and then 'emerge trb' or the like.
asciilifeform: rk3328-roc-cc + usb3sata snake + 1tb mech hdd -- might potentially make a working ~100bux trb node. worth a shot, shinohai , if you have a free hand.
asciilifeform: shinohai: prolly the best result re trb on rockchip would be with 'adult' samsung sata ssd via usb3-sata snake ( you can buy short one, that fits in box )
asciilifeform: mircea_popescu: to bake a e.g. iron trbi, or the like, you'd need to init and talk to the sata card, this is not given in the example ( but not particularly difficult )
asciilifeform: while imho this is not a 'let's do this right nao' scheme, it is prolly the Right Thing in re 'trb-i' block propagation. no moar 'block withholding' nonsense. no reason why trbi should not own ionosphere the same way mircea_popescu projected bitcoin will 'own' mains current generation capacity.
asciilifeform: mircea_popescu: asciilifeform routinely misremembers having v 4y ago. prolly because we were already doing signed chains of patches since day0 of trb. hand-cranked v.
asciilifeform: i cut winblowz #ifdefolade out of trb because i did not read it and don't intend to.
asciilifeform: it is for this reason that asciilifeform cut most ( unfortunately not all, there is room for improvement! ) ifdefolade, out of trb.
asciilifeform: i abolished it in trb ( rotor ) , ave1 -- for gnat, and really ought to end with the logical conclusion, standard cuntoo musl/headers/gcc.
asciilifeform: there's no rsa in trb
asciilifeform: ( why? because asciilifeform doesn't like to crypto in any form, even as toy, on boxes without rng, and some of his trb dev machines at the time had none )
mircea_popescu: http://btcbase.org/log/2018-06-26#1829715 << nah, trb is the bulkiest and most dangerous item on the table, it utterly can't be the exemplar at this early stage.
asciilifeform: the 'is it same trb' is much smaller problem than it seems, is quite resolvable mechanically ( as demonstrated in my http://therealbitcoin.org/ml/btc-dev/2018-April/000296.html experiment , for instance )
mircea_popescu: much better than having to resolve the "is it same trb" problem. what's the drawback ?
asciilifeform: ben_vulpes: at one time i tried to implement more or less same item you're making, and did the shiva thing, and in the end thought that whoever it was ( mircea_popescu ? ) who suggested that trb should simply eat ( and prompt to sign ) raw tx, generated externally via scripts, was right
asciilifeform: ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb
asciilifeform: eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc
mircea_popescu: mod6 backups are your friend! this whole trb stuff is a little friable.
mircea_popescu: if you try to send it with a lower fee than the level you set it to use it'll throw an error ; the rule for trb is to throw useless incomprehensible if not outright misguiding errors.
mircea_popescu: is this trb ?
asciilifeform: ben_vulpes: trb is happy to ~eat~ anyonecanspendolade, just won't shit it
asciilifeform if it wasnt clear, highly disrecommends the continued use of shiva/tscheme for anyffing trb-related
asciilifeform: compared to, e.g., trb reactor dismantlement and rod replacement , re-creating the useful part of emacs is light work.
mircea_popescu: asciilifeform no but this is my point. "why are you using emacs when in fact trb will need ada scheme anyway and then you could just have a musl-gnat nerwmacs" ?
mircea_popescu: but no, it's not like it's verboten to stand up a trb, god forbid.
mircea_popescu: http://btcbase.org/log/2018-06-21#1827994 << yes but this won't likely work here ; the dependency tree is like 10x trb's.
asciilifeform: Mocky: as you are prolly already beginning to understand from the l0gz, vtronics grew from trb work, which demanded 'measure not 7, but 7777 times, before cutting once', in the style of http://btcbase.org/log/2014-11-15#922644
asciilifeform: Mocky: even quite small changes to trb, typically get months ( sometimes yrs.. ) of discussion, testing.
asciilifeform: Mocky: trb , roughly speaking , is a legacy item, in the same way as the icbm targeting comp and similar. i.e. a museum piece that gotta be kept in working order, rather than 'sexy, new' thing bubbling with development
asciilifeform: Mocky: on the list of serious problems in trbworld, it ranked somewhere near bottom.
asciilifeform: Mocky: the rpc thing is ugly and there were experiments re replacing it ( e.g. 'shiva', scheme interpreter bolted on to trb ) but this took a back seat to moar pressing matters ( control of memory footprint ; sane sync behaviour; coupla other items ) and to this day rpc is still there.
asciilifeform: i solved this same problem for trb -- i.e. building 100% musltronic proggy with '9000' deps , on a conventional box
asciilifeform: just like in earlier rotor-trb.
asciilifeform: just about errything that doesn't abuse some glibc-specific knob, runs 100% under muslism ( e.g. trb, which was the first proggy i personally built for musl, back in the http://therealbitcoin.org/ml/btc-dev/2015-July/000133.html days )
asciilifeform: situation quite reminiscent of bitcoin immediately prior to trb
asciilifeform: phf: this really calls for a ben_vulpes-on-trb-style archaeological dig
asciilifeform: by this logic could just as well omit trb from cuntoo
asciilifeform: ergo gotta have a trb-frozen emacs.
asciilifeform: ( granted, a defective 'replacement for trb' will give you a reactor meltdown, whereas a climacs-like abortion will simply create grumbling would-be users who revert back to emacsism )
asciilifeform: it's about on par with full replacement of trb.
asciilifeform: phf: slime aint exactly trb, it's, what, 50kB ?
asciilifeform: http://btcbase.org/log/2018-06-19#1826979 << phf i for one would not be opposed to 'rewind to 19 and patch as-needed', like we did with trb.
asciilifeform: mircea_popescu: the best object of comparison is imho trb.
asciilifeform: thing is quite ripe for the trb treatment.
asciilifeform: e.g. trb genesis , weighed ~900K , not so far.
asciilifeform: mircea_popescu: pogo ? they're as usable as ever as soon as somebody gets trb into 256MB, lol
asciilifeform: and generally treasurer and instigator oughta be different people. as in the trb foundation.
asciilifeform: i did most of the early trb on that thing
asciilifeform: junkyard wars (e.g. trb, mp-wp) where one is stuck welding a tank from 5 zaporozhets and 3 lada carcasses, because that's what there is to work with, inevitably are heavyweight
asciilifeform: trb is, what, 25k-loc.
asciilifeform: phf: trb is, what, 800kB, and already imho 'weighs' ~10+ yrs worth of study to fully grasp
asciilifeform: in other funnies: the preface in http://btcinfo.sdf.org/blog/trb-build-instructions.html .
asciilifeform: certainly nogood for trb.
asciilifeform: ( c2 feels, to asciilifeform , even 'longer ago', epochally -- even such a basic thing as trb, say, did not yet exist )
mircea_popescu: for instance : bitcoinfs may be found useful by someone storing flac muzak. they'd then copy it from its original tmsr-os / trb tree, and put it in their gp-os / torrent tree.
mircea_popescu: but should eg, bitcoin-fs be written, then yes trb will exist in the same tree as bitcoin-fs. and should we go as low as tmsr-os, then yes, tmsr-os as genesis will have bitcoin-fs patchzone and then trb patchzone after that. and people wanting to use bitcoinfs for something else can just press up to there and no further. and projects wanting to import bitcoinfs but not trb will just build off that height of tree, and continue
asciilifeform: douchebag: you did ~only~ the minimal interpretation of what was asked. like a schoolboy. instead of, e.g., annotating this list with 'is this an actual vuln in actual physical trb'
asciilifeform: and i still don't seen any vulns in anything that actually gets linked to AND CALLED FROM trb
mircea_popescu: trb, also, ball of cpp.
mircea_popescu: http://btcbase.org/log/2018-05-08#1811085 << minigame would host it ; so would deedbot. you saw the trb build style, specifically http://thebitcoin.foundation/trb-howto.html (the parts where it goes 'curl http://deedbot.org/deed-430460-2.txt > rotor.tar.gz.asc')
asciilifeform: lobbes: http://btcbase.org/log/2018-05-05#1810194 << exactly it. your musl gcc never built, so trb has nothing to be built ~with~. you must find out why it did not build. but i recommend burning your heathen linux to the ground and using danielpbarron's, or trinque's, or mine, gentoo recipe
asciilifeform: ben_vulpes: the only thing preventing trb on the existing pilotplant rockchippen is the small disk.
asciilifeform: ben_vulpes: RC will trbate, if you give it large disk
asciilifeform: lobbes, other trbists : another thing that worx, is the combo of pizarro node piped through a cheapo heathen relay-only box.
asciilifeform: mircea_popescu: i'd like to get a sense of what gets douchebag's pulse going, is all. cuz trb evidently doesnt
asciilifeform: ~then~ builds trb.
asciilifeform: http://thebitcoin.foundation/trb-howto.html
asciilifeform: mircea_popescu: not only list, but full set of signed tarballs, on trb.org
mircea_popescu: asciilifeform, afaik there isn't anywhere a complete list of specified versioning for trb, nor ever was.
asciilifeform: douchebag: pleeez consider at least attempting to read the trb materials at therealbitcoin.org ?
asciilifeform: mod6: the included illustration was to the effect of 'what if trb had been made using this type of vtron, from genesis to present day' .
asciilifeform: mod6: the press (using ordinary v) creates a text file, 'trb'. which then is 'untarred', if you will, to 'makefiles' .
asciilifeform: iirc this was a headache in early trb days
mircea_popescu: mod6, was a while ago. but anyway, nevermind, you'll do all this later. get tx tooling into trb, by all means.
asciilifeform: and the 'tldr' of it is: if you download the patches/sigs in the example, and press to any particular one, you get a file 'trb', which, when put through included proggy 'txt2dir' results in a bitwise-correct (i.e. bit-identical to classical tree that we have for trb) press.
asciilifeform: ( if you grab the attachments of the ml post, and follow the instructions, you get bitwise-identical trb on every step of the ladder , vs the respective trb at that step in the orig tree . )
asciilifeform: mod6: considering that the example i gave ~is~ the totality of the trb tree, i'm a bit puzzled, what was it you tried ?
asciilifeform: in other quasi-noose, heathen node walker ( https://archive.li/FHKym today's snapshot ) reports 11 advertised trb nodez, with 9 of'em at tip-top of currentchain . iirc of the 9, 2 are actually 1 BingoBoingo box. still seems like 'aggression' worx pretty well.
mircea_popescu: http://btcbase.org/log/2018-04-21#1804340 << approximately none. trb ran without trusted node list for years.
mircea_popescu: think about it, if 500 nodes want to talk to bbistan, each local trb will talk to 500/n
mircea_popescu: consider also that especioally b is problematic as trb isn';t ~really~ intended to be used in a home environment ; and racked servers may not provide your video whatever.
mircea_popescu: afaik trb comes cli only ; you can add a gui but a) you'd have to write it and b) it'd necessarily introduce dependencies.
mircea_popescu: now, kako for all his weird was certainly technically competent, so it's not the case that "there lay a trb in the rain".
asciilifeform: it resembles 'nano ecc' which at 1 point asciilifeform tried to port to trb
mircea_popescu: running trb offers a firm guarantee that you will have your coins perpetually. running the various usg-sponsored "i can't believe it's not bitcoin" margerine offers a firm guarantee that a) any time you spend with them will be wasted on a long enough timeline and b) any resources you spend with them will be worthless on a long enough timeline. so bear that in mind.
asciilifeform: trinque: theoretically 'every private has a marshal's baton in his knapsack', but realistically it is not esp. likely that 'popping trb' had to wait for this 1 d00d to turn 19 or what he was.
mircea_popescu: the republic's de facto moving towards hardware specialization, there's on one hand the very heavy cpu machines (of which sha miners are a subset, phuctor is another, and so on), and then the sort of thing like this, typified by a trb node machine.
asciilifeform: (trb, buildroot-kernel, userlands)
asciilifeform: chipset is a 'rockchip', i ported trb to it in 2015 iirc.
mircea_popescu: douchebag alf lands in the oriental republic sometime mid month ; you'll get your login then, an' your first task will be to get trb up on it ; and the tasks 2 throught 999 will be to have fun.
mircea_popescu: ah so could actually run trb np
mircea_popescu: douchebag i'll get you a sever once the pizarro folk unwrap their heads enough to actually have one on offer. so you can tinker on gentoo, trb etc and get out of the "vps" bs hell.
asciilifeform: when i was actively trbing, i handled 'want p1 + p2 + ... p_n ' by hand-copy and producing p_n+1
asciilifeform: phf: can you give a concrete press head for current-trb that will barf if the lateral-walk is removed ?
mircea_popescu: or possibly everyone regarded trb as a messy pile which isn't properly v-ified even today. like mpi, or like gentoo
mircea_popescu: terrible idea to do it on trb. no, you want to do it on something small and simple, speciifcallty because "it's not hard to regrind existing tree"
mircea_popescu: http://btcbase.org/log/2018-03-23#1789035 << in trb you mean ? not likely.
asciilifeform: ben_vulpes: there's quite likely enuff coin just in trb hotwallets, to buy a flotilla. and if you can get to it, it's as yours as your own nose, nobody could do a thing about it. so wtf are you doing fucking with php.
asciilifeform: for that matter, why does douchebag settle for small change of www ? a remote ex for trb or even prb will easily bring in enuff loot to buy a battleship. without having to convince anybody, i'll note, of anything.
asciilifeform: possibly funnily , early in trb life , asciilifeform on a lark put it through a $maxint scamolade 'cpp security auditor' proggy that the imperial slavegalley he was working in, had bought. the result -- unsuprisingly to tuned-in folx, i expect -- was so unremarkable that i did not bother to post it.
asciilifeform: as discussed, re e.g. trb.
asciilifeform: i dun think more than a week has gone by, at any point since trb first proclaimed , when trb was not mentioned in some way
asciilifeform: douchebag: why limited to 'web framework' ? if you consider yerself fit for work in hard/unsolved problems -- why not go and find remotely exploitable boojum for trb
asciilifeform: trinque : out of curiosity : do you see, e.g., asciilifeform's amputation of all microshit #ifdef... crapola from trb, as mistake ? 'fails to strategically engage the world-as-it-is' ?
asciilifeform: mircea_popescu: 'rockchip' rk series. asciilifeform ported trb to these in 2015.
asciilifeform: (why, is separate q : perhaps a testing trb, and a classical trb ? )
asciilifeform: i also using for years. but suppose you wanted to run two instances of trb on one box, on separate ips.
asciilifeform: quasi-relatedly, seems like BingoBoingo has already not 1 but 2 working and synced trb nodez
asciilifeform: iirc fella mostly lurks, but quietly runs a trb node, obtained a FG ( but afaik not yet written any study of it, no blog yet ) , is literate tho
asciilifeform: ben_vulpes: post to the trb ml, sort what it's for
mircea_popescu: http://btcbase.org/log/2018-02-07#1782339 << sadly, i dun see how bbisp could provide platter. for one thing, it takes way the fuck more power. for the other, it simply dun work for one of the more important republican apps, teh trb. it's just... not there.
mircea_popescu: trinque yeah, i have no clear model in my head of what's going on. but, i expect most load other than trb will be apache or something like it. and in my experience higher clock beats more cores once you have more than 4 or so, there.
asciilifeform: ( y'know, exactly like whoever wants to , can mirror trb universe )
asciilifeform: ( at some point we will have to solve the puzzle of just how many trb nodes it makes sense to have inside 1 cage, i also suspect )
asciilifeform: BingoBoingo: be sure to use trb with sync sanity, cuts sync time from 6+months to coupla weeks at worst
asciilifeform: but trb nodes really oughta all be within a few blox of one another at all times.
asciilifeform: it's one thing where prb refuses to serve trb node blox, or puts out some oddball liquishit that gets it malleus'd, etc
asciilifeform: mod6: let's restate the general principle. if you have two or moar trb nodes, and they are 'in communion' with one another regularly, and yet one is several 100 blox behind the other(s) -- THIS IS A BUG
asciilifeform: observe also that even 'aggressive' trb only demands newblox when a peer ~connects~
mircea_popescu: trb is whatever the foundation releases.
asciilifeform: it ain't retrofittable to trb imho, however. too many inoperable tumours in trb.
mircea_popescu: but it;s not that machine is useless "for trb work". current trb is useless for machine work.
mircea_popescu: http://btcbase.org/log/2018-01-27#1777409 << a properly rewritten trb-blockchain would actually work ok on plated disks.
asciilifeform: http://btcbase.org/log/2018-01-27#1777388 << at the risk of repeating -- mechanical hdd is ~useless for trb work
asciilifeform: mod6: this was in response to a hypothetical 'but why do we even need releases' , not re current trb www
asciilifeform: granted this is less of a headache in 'minerless' trbi variants.
asciilifeform: ( dulap had ~ok trb performance on spinning rust, but it had striped raid . and STILL couldn't keep up with ssd zoolag, despite the latter being a box the size of my fist, with no raid, on residential fiber )
asciilifeform: n00b wants to run trb. which trb will he run ?
asciilifeform: imho 'trb release' makes sense as a thing -- conservative 'this worx' item
asciilifeform: in trbland
asciilifeform: it means, simply enuff, whatever item ben_vulpes & mod6 proclaim 'this is a trb release'
asciilifeform: the old sync behaviour is profoundly retarded tho, asciilifeform felt quite stupid for not having fixed it in the first yr of trb's life
asciilifeform finds the 'tx references outputs of old tx, rather than addrs' to be a profoundly trisomistic shitoshiism -- but we can come back to this at next 'trb-i' thread
asciilifeform: trinque: which trb is this
asciilifeform: !!rate shinohai 3 heathendom newsdesk; pogotronics, trb, FG experimenter
asciilifeform: !!rate danielpbarron 3 operates heathenbux-denominated FUCKGOATS dealership; trb experimenter; history of doing The Right Thing
asciilifeform: in other oddities from asciilifeform's wwwtron referlog : http://armoredcoin.org << anybody here wants to confess to authorship of this ? it claims interop with trb , compliance with asciilifeform's '7laws' , etc
asciilifeform: the trb treatment.
asciilifeform: http://btcbase.org/log/2018-01-22#1774125 << phf neato. mod6 : prolly this oughta go instead of the old one, in trb www.
mircea_popescu: you know ftr trb node state of blockpool has improved tremendously.
asciilifeform: apeloyee: look at the trb tree, and picture what the mass of the patches would have been, if this requirement had been in effect when i made it.
asciilifeform: as i did in trb.
asciilifeform: trinque: first step is to genesis a gnat. ~then~ patches... a la trb
asciilifeform: their cumulative mass dwarfs , e.g., trb.
asciilifeform: http://btcbase.org/log/2018-01-06#1765881 << sanity looks like this : 'trb since 2015 is made of v. and works. and quite compact. and fundamentally mechanics are correct.'
asciilifeform: if trb tree can continue to look EXACTLY like http://btcbase.org/patches ( with new leaves growing ) -- your vtron is usable. if not -- not.
asciilifeform: trinque: consider how i solved this in trb.
asciilifeform: btw what does trb's ssl do with crafted der-encoded derpery ?
asciilifeform: !~later tell trinque how does deedbot's block-fetch history for past 2wk look ? zoolag's performed very, very well re 'tip of spear' , and there appear to exist at least 5 other fully-synced trb boxen that regularly speak to it.
asciilifeform: item aint strictly about 'clouds' tho, quite broad, includes errything from www browsers with scripting, to , potentially, trb's commandprocessor
asciilifeform: i expect there'll be plenty of rubbish in the genesis. as there was in trb.
asciilifeform: ( in particular the orphanages amputations. good chunk of bandwidth is TO THIS. DAY. wasted , by prbtrons throwing their liquishit at trbtron )
asciilifeform: the intrinsic difficulty of a trbtron's job is more or less 100% in dealing-with-prb.
asciilifeform: in mostly but not wholly-unrelated noose, asciilifeform searched the market for little lcd thing one could plug into usb jack, to have trbtron display height at all times while it sits on the shelf. but TO THIS DAY none exist that cost less than THE FUCKING MACHINE lol
asciilifeform: 99.99999%+ of what gets 'pushed' to a trb node, is thrown straight into the rubbish
asciilifeform: pushing dun do much for a trb node, who needs at any given time THAT ONE SPECIFIC NEXT block
asciilifeform: mod6 plox to re-add zoolag to trb roster.
asciilifeform: BingoBoingo: i am looking to set up a handful of trb nodez 1) small, 'disposable' boxen 2) for fiatolade 3) with decent , i.e. at least 100mb symmetric ea. 4) NOT all in same cage
mircea_popescu: incidentally, the fresh blood you (and trinque ) pumped in trb ecosystem made a lot of secondary nodes gain lots of speed too.
asciilifeform: as for nodes at the 'tip', the path of chinesium through layers of prb is a lottery, and i suspect that attempting to measure the effect of a trb patch on said behaviour is doomed to astrologize over noise
asciilifeform: if it dun have a trb genesis, proving to proverbial martian that it really does have classical 0.5.3 pedigree, goes from trivial to monumentallypainful
mircea_popescu: ie, i don't expect the trb cut as described to have a trb genesis necessariyl, or even probably.
mircea_popescu: there's nothing wrong either in principle or in practice with making a correct item as the genesis and then patching in various parts of trb.
asciilifeform: asciilifeform introduced the schemetron 1st, and only 2nd the glue in trb, and they were not automagically v-linked
asciilifeform: ben_vulpes: ( trinque ? ) what ~concrete~ operation on trb tree did v-as-it-nao-exists keep you from easily carrying out ? i'd like to see ?
asciilifeform: ( i.e. it is already inescapably linear. asciilifeform half-expected that the kakoschism would produce a long-playing split of the trb universe, but neverhappened. not every possible thing, happens... )
asciilifeform: http://btcbase.org/log/2017-12-26#1758779 << i see e.g. trb tree, as the frayed end of a rope. in long term, observe, the loose ends that dun get built on -- fade away, like orphan chains. btc is actually more or less same kind of system. but iirc we had this thread.
asciilifeform: which, in the whole picture, does not come close to topping the list of the hardest labours of a trb experimenter
asciilifeform: i can't speak for others, but asciilifeform often ( almost always, in fact ) runs trb during tests, in pure userland, making use of 0 systemwide loggings )
asciilifeform: what i'd like to see is 'was it from a trb?'
asciilifeform: that already printed ( the latter , in classical trb, mutilated )
mircea_popescu: but honestly i'd prioritize db-fix-and-trb-split discussed over these rather cosmetic by comparison improvements.
asciilifeform: exactly like what an unpatched trb does for first hour or three of boot
mircea_popescu: trb dun get malleus'd anyway
asciilifeform: well right nao it's pulling blox from other trb's, at ~100% efficiency
asciilifeform: ... as mircea_popescu prolly intuited , it remains possible that 'aggression' takes the trb<->prb link breakage from , say, the 80% of before, to 100% , and i would not learn about it until reaching tip.
mircea_popescu: for as long as you have other trbs up to speed to support you. but still, useful mod.
asciilifeform: it did take a while to reach this state, given as 'wires' are no longer in use. had to actually connect to a working and nonblackholed trb.
asciilifeform: this is testable empirically; like-so: any N trb nodes built with 'aggression' patch above, and linked via 'wires', should never fall out of height-sync with one another by more than a coupla blox. at any point.
asciilifeform: *where any 2 trb nodes connect, and...
asciilifeform: analysis so far : ^^item^^ results , at last , in situation where any 2 trb nodes, and 1 is 'ahead' of the other, the 'trailing' node is guaranteed to be fed.
asciilifeform: !~later tell trinque where didja get the log-timestamps in your trb ? ( which patch pressed to ? )
asciilifeform: shinohai: trb needs a disk
asciilifeform: anybody got 2 trb-capable boxen, on separate ip but equal in bw ? can be in heathendom isp or wherever.
asciilifeform: and speaking of hasty and untested , asciilifeform has a 'aggressive sync mode' trb patch, which will need a proper differential test
asciilifeform: as i understood trb historically was 'and here is bitcoin minus the post-2011 barnacles, deviate at your own risk, derps, it will still be there an' working'
asciilifeform: ideally reference-trb is capable-of-everything, incl. cpumining ( see the dozen or so threads at this point )
mircea_popescu: anyway, continuing the trinque discussion, it seems entirely unavoidable that trb will become 3 things : a wallet node, optimized for pumping out local signed tx ; a block node, optimized for keeping the blockchain, getting blocks, no mempool nonsense ; and a spy node, optimized to keeping track of the lies and nonsense flowing through the relay network (mempool, timing nodes, what have you).
mircea_popescu: bb broadfly has it, there's a narrow sliver of bw trb/prb can even use ; more than that it generally wastes.
mircea_popescu: by the time your trb node eats 10 MBps even, you've more serious problems than "buy more pipe". and that's inst not sustained.
asciilifeform: mircea_popescu: should hope so. because 100mb ain't enuff for even 1 trbtron
mircea_popescu: in other sads : one trb node was dead since fucking 22nd of august, because -- it ran into the fabled "terminate called after throwing an instance of 'DbRunRecoveryException' what(): DbEnv::txn_checkpoint: DB_RUNRECOVERY: Fatal error, run database recovery" which then kicked in a script to clean it up, which it did, but couldn't boot back up because for yet-unknown reasons there was a spurious .lock leftover ; corner case u
asciilifeform: trinque: the 1 common thread in asciilifeform's lab notes from birth of trb to today, is that once they fall behind, they stay behind, until reset. (often more than one reset.)
asciilifeform: aside from brief period at bootup, a trb node DOES NOT TRY TO SYNC AT ALL, passively waits for someone to come and feed it. forever.
asciilifeform: quite heavy compared to even, say, trb.
asciilifeform: btw some very large share of 'no can haz trb, plz help' in the logs to date, feature shituntu
asciilifeform: pretty sure that mod6 hosts a curl, at trb www
asciilifeform: fact is, trb sync is ragingly retarded. as in , microshit-level.
asciilifeform contemplates placing trb on ramdisk on this box
asciilifeform: but the results ( at least in asciilifeform's torture room ) have been disappointing, currently afaik nobody even knows why bdb ignores locks knob ( perma-hosing trb ) !! under bsd
mircea_popescu: trb-as for anti-sybil.
asciilifeform: and 4G typically suffices to run trb 'year-round'.
asciilifeform: btw asciilifeform will reveal that he found a 'new' (to him) and very spiffy type of amd g-series box , suitable for trb and similar
asciilifeform trying very different tack re 'trbi' than in prev thread, instead of massive warcrime , series of small gedankenexperiment.
mircea_popescu: http://btcbase.org/log/2017-12-19#1753954 << i have up to date nodes ; both trb and legacy. but the phenomena described is recurrent since at least 18 months ago.
asciilifeform: this gedankenexperiment should be seen in light of the earlier 'all tx have absolute position and make references to absolutepositional outputs' item from earlier 'trbi' thread.
asciilifeform: nominally libc doesn't go in a gnat-baked elf, so it isn't quite the same urgency as musltronic gcc-for-trb was
asciilifeform: ( trb-genesis, for better or worse, was a plain cut of the original material. ended up preserving the idiocy of empty file. )
asciilifeform: take for instance trb , as seen in http://btcbase.org/patches/genesis/file
asciilifeform: where the linkage was ~not~ mechanically clear, because it appeared merely as a set of external symbols inside trb, rather than a proper lift of the files
asciilifeform: diana_coman: pretty sure it is same as mod6 has on trb www
asciilifeform: interestingly , this item was the 2nd thing asciilifeform ever genesised ( http://therealbitcoin.org/ml/btc-dev/2015-October/000175.html ) . 1st was trb.
asciilifeform: ( aside from some obsolete matter on trb ml )
asciilifeform: asciilifeform is also in the process of standing up trb on dulap-III , an opteron monster not yet homed.
asciilifeform: also notably, mircea_popescu , yer trb box was the champ medallist, outlived even dulap.
asciilifeform: btw mircea_popescu re 46.166.160.36 / http://thebitcoin.foundation/trusted-nodes.html : is that box still around ? because if it is, yer trb is hung
asciilifeform: but will note that, e.g., trb, builds cleanly on e.g. arm ( and iirc ppc also )
asciilifeform: or could be >0, depending on whether e.g. having trb around, is worth +
asciilifeform: all trb boxen where log wasn't cut off, have day-by-day, neh
asciilifeform: ( getting this number from a trbtron is still a manual process. )
asciilifeform: mod6: trb ml was really not imho the proper place for it: mpi is not used in trb
asciilifeform: spyked: musl however worx great, trb stands on it. and iirc trinque has an entire musltronic gentoo.
asciilifeform: http://thebitcoin.foundation/trb-howto.html << grep for gcc
asciilifeform: you can produce this mechanically. the unfortunate bit is that it gives same problem as basing trb on original 5.3.1 tarball contents did
asciilifeform: and it's a perfectly legit ( manually ground, from mpi, just like trb genesis was from 0.5.3 ) genesis.
asciilifeform: hey i still to this day use jurov's system, whenever submitting trb patch.
asciilifeform: same way we avoid gavinization of trb, for instance.
asciilifeform: if yer disk is too small to rotate debug.log by hand 1-2x/year, it is too small to run trb !!
asciilifeform does not currently have even 1 up-to-top trb node !
asciilifeform: sooner turn pig into a professor of mathematics, than cpp trb into sanity.
mircea_popescu: trinque you won't be able to fix trb into sanity without new classes.
mircea_popescu: mod6 in any case don't completely abandon the trb-v castle, you're like our last guy there i fear
asciilifeform: how would trb pay a 3, lol
asciilifeform: hey trinque check your boxes that had 'wires', they are probably STILL running, and trbing to it
asciilifeform: in other lulz, something closely resembling trb node on ex-dulap ( 46.166.165.30 ) still running... though i do not recommend it for any practical use
asciilifeform: mircea_popescu: is it working as intended, or is the result trb-like ( 'life support patient' ) ?
asciilifeform: like trb! ( but i'ma not repeat, because at this point everybody knows )
asciilifeform: ahhahaha exactlylike trb
asciilifeform: ugh sounds like trb
asciilifeform: ./v.pl p v trb54 makefiles.vpatch <<< is the answer
asciilifeform: http://btcbase.org/log/2017-10-06#1721644 << what is 'vanilla trb' ?
asciilifeform: ( btw is it clear that buildroot is only part of the trb universe because we dun have a musltronic linux to do ordinary stator builds in ? )
asciilifeform: and iirc we also had thread re how crapple is not in business because asciilifeform reads trb coad and 1970s 'химия и жизнь' on a crappad
asciilifeform: ( remember, an unsynced trb node rejects ~ALL tx )
asciilifeform: ^ asciilifeform's very painstaking 'trbfication' of koch
asciilifeform: diana_coman: and in your trb wot dir likewise.
asciilifeform: http://btcbase.org/log/2017-09-14#1714258 << funkenstein was an odd d00d: shat on trb, but lifted it wholesale for use in his altwhatever; today hangs in kakolandia and misses no chance to hurrdurrmpisafraud etc
asciilifeform: and so long all trb nodes ?
mircea_popescu: rothbart if you have it in a portable data format, can just feed it into trb
asciilifeform: 1) move the btc using trb, to new addr 2) import (now empty on btc chain) privkey into shitcoin node 3) empty the shitcoins into a gox 4) sell
asciilifeform: move the btc using a trb node
mircea_popescu: it'd help if we first had a trb wallet model.
asciilifeform: http://btcbase.org/log/2017-09-10#1711819 << prb wasn't involved here, was operating on trb .dat's
mircea_popescu: http://btcbase.org/log/2017-09-10#1711763 << yes, to fish out CHANGE addresses in trb you must FOLLOW txns trees to the unspent leaf. true pain in butt.
mircea_popescu: shinohai: "connections" : 5, << i think that's how many of the trb list are actually up atm
asciilifeform: a trb node that's perpetually months (or yearz) behind topheight, mainly sits around rejecting tx all day long
asciilifeform: because even in whole 1G i never saw trb live for >week
asciilifeform: how long your longest run of trb on pogo, danielpbarron ?
asciilifeform: it is why i work on, e.g., trb, despite having scarcely any coin personally.
asciilifeform: probably never yet seen trb, either...
mircea_popescu: ah. no i meant, is jhvh1 sitting atop a trb node feeding !~blocks
mircea_popescu: um. how would trb see the tx anyway ? it dun interpret segwit
asciilifeform: stock trb dun help much
mircea_popescu: anyway, i'm not sure what's easier, eulora install or trb install. they're very similar processes for some reason (har har)
mircea_popescu: http://btcbase.org/log/2017-08-24#1702779 << core hasn't yet hardforked from trb. their "segwit" thing is a "soft fork". basically they intend to make everyone's transactions be blockchain messages instead of actual transactions.
mircea_popescu: http://thebitcoin.foundation/trb-howto.html <<
mircea_popescu: http://btcbase.org/log/2017-08-24#1702761 << run trb. follow mod6 's instructions, it's a relatively painless half hour install on most any sane linux.
asciilifeform: the reason why mike_c's node appears 'stalled' is that it stopped fetching blocks. trb's block sync behaviour is unspeakably moronic, it will attempt 'long sync' ONCE, on warmup
asciilifeform: if trb node is not fetching blocks, but is not showing symptoms of 'black hole'
asciilifeform: !~later tell mike_c http://btcbase.org/log/2017-08-23#1702508 << this is NORMAL behaviour for a trb node. and see below re 'stalls' :
asciilifeform: mircea_popescu: hilariously wrong description of trb
mircea_popescu: i mean, a trb capable machine is somewhere in the 50-100 bux / month range, certainly an expense but not the end of the world.
asciilifeform: http://btcbase.org/log/2017-08-22#1702394 << it is zoolag, it is resyncing, and ( i assume everybody knows ) it is ~impossible to usefully connect to a trb node that is syncing
asciilifeform: spyked: trb is very long way from 'sane object' but otherwise yes.
asciilifeform: i use it in workstations. but the cost is imho misplaced in a trb node, which are supposed to be a redundancy layer p2pfully in themselves !
asciilifeform: pete_dushenski: as i understand it's a couplea line patch to trb
asciilifeform: !~later tell ben_vulpes was it you who had a trb patch abolishing the idiotic truncation of block and tx hashes in debug.log ? where did it go ?
asciilifeform: i don't much like the phrase 'trusted nodes', when you connect to trb node, you get plaintext tcp, and 0 guarantees re who or what you're actually talking to.
asciilifeform: !~later tell mike_c http://btcbase.org/log/2017-08-19#1700623 << why was it necessary to use closed turd client ? ( what's the actual diff in the lolfork anyway ? the 2mb thing ? could exist as a lulzpatch for trb, even, in principle )
asciilifeform: ACHTUNG panzers!! trb node 'zoolag' is back in business, this time as ordinary linux box -- syncing from 0 . same ip as prev.
asciilifeform: mike_c: congrats on building trb, incidentally
asciilifeform: other idea is to demonstrate that trb can work without riding on top of existing telecom structure.
asciilifeform: also interesting to mike_c will be the 'trbi' threads..
mircea_popescu: mike_c but look at the new v-based trb build
asciilifeform: the index won't read by trb.
asciilifeform: also i thought mention of mp/trb/et al were a hangin' offense at tardstalk
asciilifeform: and there's a history of trb nodes of various types perma-wedging there
asciilifeform: this thing behaves precisely like trb sans locks patch, i think
asciilifeform: i dun think it is anything to do with that tx per se -- it is the drop that overflowed the barrel in pre-dblockspatch trb
asciilifeform: until this 'not' remains, trb ain't a program, it's a voodoo incantation.
asciilifeform: naively thought 'i'll start with the smallest trb node!'
asciilifeform: trb on linux : does
asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
asciilifeform: ( no trb yet, but enough to re-pour the cement... )
asciilifeform: well i have. currently, by expecting 1 fewer trb testbed..
mircea_popescu: and ~possibly~ easier than to sanely rewrite trb
mircea_popescu: there';s no fundamental reason trb needs more than about 5mb or so of ram ; but this aside : gotta find a way to put your own ram in the damned arm boxes.
asciilifeform: trb in 256M ain't happening.
asciilifeform: extra infuriating detail -- i dun specifically need x86 for this , trb runs ok on arm. BUT all extant arms have soldered down (and insufficient) ram.
asciilifeform: btw in case this wasn't clear, this was zoolag , which did 2+ yrs of 24/7 trb.
asciilifeform: and this is true of pretty much any box that makes decent trb node (i.e. has sata3 + ssd )
asciilifeform: ( and in fact it ran on my pogo. but that doesn't produce a usable trb node. )
asciilifeform: not sure how that goes directly with trb
asciilifeform: also lol re the attempted theft of the name 'trb'/'the real bitcoin'
asciilifeform: for clarity : asciilifeform ain't inluvv with superH. but he ~does~ search for a cpu where 1) respectable (say, even trb-capable) horse 2) no internal flash rom 3) not ARM
asciilifeform: in other noose!, a samsung ssd lasts about 2y in a high-traffic trb node.
asciilifeform: ... though i can see what mircea_popescu means. prb would not, iirc, eat a highS block. and several other types that trb happily eats.
asciilifeform: interestingly asciilifeform recently learned that the 'mutate high to low S and broadcast malleated tx but ONLY if a 'doublespend attempt' ( you retransmitting, say, with patched trb ) is detected ' thing is STILL running
mircea_popescu: trb has problems resulting from being written by monkeys.
asciilifeform: it is a problem in the same way as it is for trb.
mircea_popescu: a solution to the problem would actually help trb too
mircea_popescu: or stand up a log bot, or whatever. run a trb node. run the ada implementation passed around recently of a big number calculator and produce 655356! to compare with the given values.
asciilifeform: nothing observable to ~people~ -- i.e. folx using trb -- yes. to redditus running gavincoin etc - thermonukokalypse
asciilifeform: http://gcc-melt.org << of potential trbological interest.
asciilifeform: phf: imho sampling profilers are a wholly useless thing, 'horse with pedals', unless you're working a honeywagon (e.g. virginal trb) and have deeply nfi what the hell the program is doing
asciilifeform: afaik deedbot is currently the only thing auto-signing ( inside its tx-issuing trb )
asciilifeform: hey, they gotta keep inmat^H^H^H^H^Hstudents from hosting warez/trb/etc terrorisms somehow!1111
asciilifeform: it will have to be confiscated from the monkeys, like trb was.
mircea_popescu: allows you a trb editing environment at any rate
asciilifeform: what trb item have you tested, IamAGirlsoInever ?
asciilifeform: unrelatedly, i have nfi who trb node 208.94.240.42 belongs to, but it's been stuck in the 300,000s for ~ages~
mircea_popescu: once that is in place, a proper p2p mechanism can be built and trb will work way the fuck better than prb ever could.
mircea_popescu: wires patch is not different ; still same trb.
asciilifeform: meanwhile, in the world of sad prototypes : asciilifeform discovered ( and why did it have to be ' asciilifeform discovered ...' when other folx were nominally also testing...) that trb node with 'wires' still happily falls behind by 100s of blox, and never catches up,
asciilifeform: at one time he grudgingly tested some trb
asciilifeform: reference trb gotta keep working, uninterrupted,
asciilifeform: idea , however, is that it will run blox past trad trb ( netless , mempoolless trb ) as 'final court'
asciilifeform: hence why all of asciilifeform's trb work from month or so ago and forever more, is about losing the cpp hairball.
asciilifeform: it syncs when hits a fellow trb by accident and that's mostly it.
asciilifeform: if you believe the heathen chart ('bitnodes'), 'falcon' mega-relay-network etc has ~same number of nodes as... their count of trb.
mircea_popescu: in the sense that rather make that, best make new comp. trb-i all over again.
asciilifeform: achtung, panzers! anyone who noticed that his trb wire to dulap dropped last night -- the thing was rebooted (without my permission) ~13 hours ago.
asciilifeform: and lol , mircea_popescu's lament is ~exactly asciilifeform's ~yearly 'when i stop writing trb fixes, they stop getting written'...
asciilifeform: ( before mircea_popescu balks -- 'trbi' ain't btc )
mircea_popescu: nitpick : move 2016 to 2017 on trb.org main page
mircea_popescu: what i was looking for was, supposing the whole of trb looks like : http://wotpaste.cascadianhacker.com/pastes/YOK7i/?raw=true then something like : http://wotpaste.cascadianhacker.com/pastes/qGO07/?raw=true
asciilifeform: it resembles trb 'wires' .
asciilifeform: glibc is also not supported for trb.
asciilifeform: for trb, that is.
asciilifeform: y'know, when trb sits like idiot and waits for bdb to disk i/o.
asciilifeform: ^ all but the last is mostly wasted on trb
mircea_popescu: which is how trb-i even became an item.
mircea_popescu: this adds ben_vulpes to the list of people who seriously considered the matter of snipping trbn into shape, came to ~same conclusion, ie that rewrite is unavoidable.
asciilifeform: today - 'trb-i', ciphers of known strength, a few others.
mircea_popescu: this might even fix it, but it's not certain, given the festival of adhoc magic numbers trb is also known as.
mircea_popescu: well, hopefully this problem gets resolved by crap not making it into trb-i
asciilifeform: i find it slightly outrageous that i have a pressed aluminum ratheadlinux from 1990s but not a pressed aluminum gcc4.9 or trb-genesis etc
mircea_popescu: merv, or generally the mongol reduction of persia from a coupla million to a coupla hundred thousand is the fundamental civilisational act. not the building of the scum, but the purging of it. much like "writing prb" is not an achievement in computer science ; but purging it into trb is.
asciilifeform: i propose a declaration of 'tx replacement is an attack against sane bitcoin and whoever does it, is the forker, and not us, who thereafter ban it in trb and subsequent proggies.'
asciilifeform: let's say we find that, e.g., gcc past 3.x embeds an off-by-one-ization in memcpy() , dependant on payload, and that it is triggerable specifically in trb tx processing.
asciilifeform: i have plenty of 'c machines' right here that cannot run trb (on account of 'too small addr space' or 'too slow clock', take your pick.)
mircea_popescu: asciilifeform not trb's identity was being defined. the c machine's was.
asciilifeform: at any rate this is a bizarre line of thought. trb (or rather, bitcoin, the existing network) has any kind of long term future ~strictly~ if it can be entirely separated from the cpp abortion.
mircea_popescu: yes. definition of "lisp machine" ALSO IS "item which runs trb"
asciilifeform: trb (the currently existing item) could quite conceivably run on entirely different type of machine, under emulation (smbx , for instance, shipped... believe -- a c compiler, in genera. along with fortran, ada..)
mircea_popescu: c machine does have a specific meaning, and it is "item which runs trb."
asciilifeform: ( this also ignores the -- screamingly evident -- fact of trb being ~algorithmically~ defective. as explored on several occasions here. )
mircea_popescu: "c machine" defined as "item that runs trb" is thereby fixed through becoming more apparent than it previously was.
mircea_popescu: at the very least things were learned about how trb is ~supposed to~ function, and this is sufficient to qualify it.
asciilifeform: do what you will to trb, it is still written in idiot language that does not check bounds, on idiot iron that does not check bounds.
mircea_popescu: it is trying to fix the trb, which is a component of the c machine, defined as "runs trb"
mircea_popescu: in any proper statement, all the eg trb foundation's work goes towards one fold of "fixing c machine" in this sense.
mircea_popescu: asciilifeform "runs trb".
mircea_popescu: phf yeah, but still, we have some experience with the neat trb building process. it can be done.
asciilifeform: builds static trb, bootable initrd+kernel, busybox userland, ~5MB (littleendian arm) package all in all.
asciilifeform: theoretically trb & prb permit 'tx replacement' idiocy
asciilifeform: ( possibly -- if some hero devotes several years to it, trb-style -- but even then )
asciilifeform: 'Hello asciilifeform I see on coin.dance/nodes , The Real Bitcoin is listed with the 'Emergent Consensus' feature tag. Could you tell me if that's accurate - will you follow a HF to > 1MB , and could you tell me anything about how it's implemented in TRB ? Thx!'
asciilifeform: the other open seekrit re classical trb : and afaik applies equally to various prbs : there is no means whereby to introduce a martian reorg consisting of >1 block, such that it will actually get processed.
asciilifeform: ( reorg in trb is also ~ruinously~ expensive )
asciilifeform: classical trb simply throws those out, as malformed rubbish in ProcessBlock()
asciilifeform: http://btcbase.org/log/2017-03-26#1632698 << zero instances in my trb logs to date, mp_en_viaje
asciilifeform: say, for instance, kako's 'trb is broken, won't push my p2sholade'
asciilifeform: iirc prb doesn't even maintain a socket with trb , starting with 11 or so
asciilifeform: also what patch set do you use, TomServo ? my trb doesn't have time stamps, for instance.
mircea_popescu: tbh i have nfi how you could run trb in a vps. i don't think it's possible, not really. would be certainly quite the medal of merit on any software that can handle such.
asciilifeform: ( and you couldn't put, e.g., trb in there. )
asciilifeform: ben_vulpes: http://therealbitcoin.org/ml/btc-dev/2015-January/000033.html << arm cross-flags example (from ye olde trb)
asciilifeform: bulldozer that amplifies my intelligence and makes such thing as, e.g., unravelling trb, possible, is not 'balcony tomato'.
asciilifeform: ( anyone here tried trb on bigendian ? i -- have not )
asciilifeform: http://btcbase.org/log/2017-03-20#1629232 << trbi, with the fixed-length-everythings, needs ~no fancy indexer at all. it's for a hypothetical sane-trb.
asciilifeform: davout: per current trb rules (which , see earlier, is different from prb's ! even) A gotta be spent before it can reappear.
asciilifeform: if you can re-introduce an old coinbase -- which you can , if it has been spent, per trb rules -- you (or anyone else) can afterwards reintroduce any and all tx that had that coinbase as an input
asciilifeform: trb, i will note, already will not relay any attempt to spend anything not already in a block.
asciilifeform: ^ this is a question that can be answered exactly , using a patched trb
asciilifeform: it would instead manifest as one or more chains of tx that a trb node -- a particular one, that saw the particular magic orphan -- mysteriously does not want to spend the outputs of.
asciilifeform: now for the practical consequence. what this means, as far as i can tell, is that there can exist -- may already exist -- chains of tx in trb, that cannot be walked back to a coinbase.
asciilifeform: trb as it exists , permits a new tx having same hash as old, so long as old one was spent.
asciilifeform: 50* was spent, and per trb rules, garbagecollected from the index
asciilifeform: as i understand, it will validate, in trb.
asciilifeform: sooo per my reckoning, you can have sane-trb-indexer, but now every tx gotta have a field for 'was replaced?' -- and if bit is set, indexer goes and looks at the collision table, the previous lookup now 'didn't count'
asciilifeform: also it is not clear to me that trb ever... worked, in the customary sense of the word. what, for instance, happens if you actually carry out the -- entirely legal per all known btctrons -- replacement of a ~spent~ coinbase tx ?
asciilifeform: but possibly now mircea_popescu sees what asciilifeform meant by 'trbi is much EASIER problem than working-trb'
asciilifeform: and i don't mean trb
mircea_popescu: this is at the core of the argument in favour of a trb-i implementation.
asciilifeform: this is not an original discovery, there's a magic case for it in trb
asciilifeform: mircea_popescu: 90% of the retardation of trb is that objects live in heap and are all part of a massive ball of yarn, linked to one another
mircea_popescu: tho trb was made to adhere pretty closely.
asciilifeform: that thing also runs various housekeeping systems, aside from trb. like a champ.
mircea_popescu: honestly, it should just be a patch. there's no serious reason to allow the usage of trb on tiny boxes
mircea_popescu: after all, dead & replaced trb === fork.
asciilifeform: sorta the point of trb.
asciilifeform: accepts a block that ye olde trb wouldn'tve
asciilifeform: Framedragger: at the risk of repeating old thread : there is no way to 'replace bitcoin with trbi'. it isn't a thing that can be done.
asciilifeform: ACHTUNG, panzers! ben_vulpes , trinque : trb node at dulap will be unavailable for next ~hour .
asciilifeform: if i had a ticket to the mythical planet where programmers aren't retarded and 'the shame of poverty' is not smelled, we would not even be having the trb conversation.
asciilifeform: trinque: don't put wire-trb on your icbm-controller box. the skull is there for a reason.
mircea_popescu: ok, so now with the built trb with ssh patch...
asciilifeform: and you aint backing up 'this box' but the trb deps. that got frozen 4evah.
mircea_popescu: [~/trb2016-02-20/trb54]$ make ftr ?
asciilifeform: mv ~/trb2016-02-20/trbfoo/bitcoin ~/trb2016-02-20/trb54/bitcoin
asciilifeform: rm -rf ~/trb2016-02-20/trb54/bitcoin
mircea_popescu: mv ~/trb2016-02-20/trbfoo/bitcoin/* ~/trb2016-02-20/trb54/bitcoin/* ?
asciilifeform: mircea_popescu: now all you gotta do is to move the subdir 'bitcoin' inside this 'trbfoo' to replace the 'bitcoin' dir in trb54
asciilifeform: mircea_popescu: you pasted the .gitignore from inside the resulting dir 'trbfoo' ? make sure this was so ?
asciilifeform: ./v.pl p v trbfoo asciilifeform_wires_rev1.vpatch
mircea_popescu: that build happened in ~/trb/rotor/TEST2 etc
mircea_popescu: /trb2016-02-20/trb54/bitcoin/bin <
asciilifeform: rm -rf trb54
asciilifeform: ( which iirc mircea_popescu and also hanbot successfully used to build trb )
asciilifeform: your copy of this turd (quite unnecessary in trb, in fact, but that's besides the point, we inherited it in genesis) consists of the original concatenated to itself !
mircea_popescu: File: trb54/bitcoin/.gitignore
asciilifeform: ./v.pl p v trb54 asciilifeform_wires_rev1.vpatch
asciilifeform: that's where all of the patches from which trb is made, live.
asciilifeform: see mod6's document, step '0x09) `mkdir patches` Gather trb vpatches from http://thebitcoin.foundation/v/patches in which ever manner suits you best.'
asciilifeform: http://thebitcoin.foundation/trb-howto.html <<
mircea_popescu: so where's the trb+wires recipe ?
asciilifeform: this presupposes that you have a trb+wires built
mircea_popescu: it means you feed a trb to be tested randomly generated "txn"
asciilifeform: mircea_popescu: i was attempting a nonretarded trb-fs.
asciilifeform: http://btcbase.org/log/2017-03-11#1626033 << noshit! but it can only happen in trbi
mircea_popescu: anyway, proper adatron -> trb-i -> fixed 2/2 txn model.
asciilifeform: unrelatedly, i have combed trb src for a cap on tx input and output maxima, and found none
asciilifeform: mircea_popescu: unrelatedly, didja ever calculate what would happen to trb (or for that matter prb) if one were to produce a colliding txid ?
asciilifeform: seems like a shit idea tho. 'oops there isn't a trb running on dulap, because ooops i broke the build'
asciilifeform: without gutting and replacing the entire logic of trb.
asciilifeform: sooo mircea_popescu , to revisit upstack , the entire doublespendpreventer mechanism in trb relies on this nonsense , http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#0855 << is where it marks spent, and http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#0847 is the doublespendtrap
asciilifeform: if trb is in a state of snake tongue, ALL of the affected tx do not belong in the index table
asciilifeform: meanwhile, opened the binder of horrors, with trb src, and found some lulz, which is actually what i sat down at the terminal to share:
asciilifeform: the other fundamental problem, and the reason why asciilifeform's interest in recycling old fs for trb is ~0, is that imho trb needs LESS dependency on open sores crud, rather than moar
asciilifeform: phf: you're quite right that it isn't. thing is an astonishing pile of gnarl. but all of the necessary info, is ~inside~ it, just like 'bitcoin' lives inside the rubbish of trb
mircea_popescu: and this is a very important point, and cogent throughout, including re trb-i design
asciilifeform: i contemplate it as more of a 'demolition charge', when trbi exists.
asciilifeform: trb will not even need to know whether it was given a real disk, or flat file.
asciilifeform: much cheaper to reindex a trb node, what, 1 night, than for enemy to bake new asics.
asciilifeform: (i would hope that l1 will last until trbi..)
asciilifeform: if you start seeing them ~regularly~ (say, trb makes it to 50 yrs from nao) you put in a l2 table.
asciilifeform: imho the 'hard part' is not even to implement this table, it is freshman homework, but to unravel the liquishit in trb and learn where to even put the lookup/write !
asciilifeform: i was recently considering implementing a similar scheme for phuctor, and realized today that it would work entirely well in trb.
asciilifeform: if you want to consider 'what would give best performance on the iron we have, with minimal moving parts, with the trb we have' this is what comes out.
asciilifeform: so in practice, you can have O(1) seeks ~while~ storing the blocks back-to-back in a classical trb.
asciilifeform: this form will almost certainly suffice for another decade of trb
asciilifeform: the Right Thing would probably be to have a very simple kernel driver that takes a specially-marked disk partition and gives userland trb linear use of it, as plain array
asciilifeform: who the fuck wants trb running as root
asciilifeform: it exists (wallet idiocy aside) in trb for 1 purpose and 1 purpose only
asciilifeform: let's put down in the log, what exactly ye olde bdb does, that eats 99+% of trb's wall clock:
asciilifeform: if you gotta actually break compatibility with ext4 and write new kernelspace driver -- may as well design proper (b-tree) fs for trb.
mircea_popescu: so trb-ing is a huge anti-impedancer for everyone who could be working on it.
mircea_popescu: anyway, but the "i go write trbi" thing is not particularly useful as an exercise in solipsism, herculean or otherwise.
asciilifeform: mircea_popescu: since we're on subj of 'trbi', i was hoping to see the thread continue, re whether mempools, or whether my particular, or some other, scheme for abolition of mempool can be made to work , and so forth
asciilifeform: i oughta be quite specific re : 'nobody wants'. say i write a trbi, along one of the described schemes. nao wat -- mircea_popescu mines it ? and after this, who will want it ? 'just another premined alt!111' etc.
asciilifeform: the thing that cools asciilifeform's enthusiasm re 'trbi' to somewhere south of 3 kelvin, is that it isn't clear to him that anybody actually wants this, for something
asciilifeform: but this find is applicable, sadly, ~only~ to trbi
mircea_popescu: if they manage to stumble in their own robes and throusers until 2030 or so, trb might even live!
asciilifeform: paradoxically a trb-i is light years easier than 'cleaned trb'
mircea_popescu: aanyway, FG patch for trb wouldn't hurt.
asciilifeform: it is interesting how much, imho, moar readable these are, than trb.
asciilifeform: ( incidentally, trb doesn't validate scripts in blocks. at. all. )
asciilifeform: which is why you'll often find trb-related tcp pipes randomly RST'd, and the like.
mircea_popescu: if net-trb decides to engage in a reorg, it will eventually induce one in all the wallet-trbs connected to it.
mircea_popescu: meh. wallet doesn't NOT store the chain. it's just stock trb.
mircea_popescu: then also conceivably the changes will be backported into trb main once well tested
mircea_popescu: conceivably can use current trb as your genesis for this.
mircea_popescu: then you can take stock trb, operate on it, and so people interested can pick both version, have internal-external couple.
mircea_popescu: you can just take stock trb, operate on it, and place it so it only connects to operator-specified trb nodes.
mircea_popescu: this'd be wallet-trb.
mircea_popescu: node-trb.
mircea_popescu: trb too, for now, i guess.
asciilifeform: no one will ever confuse anything we might recognize as trb for any artifact from the distant Planet of Sane People.
asciilifeform: because Being Able To Use Bitcoin might pay the bills, for node operator today (or may not, some folx are stuck operating a node for other reasons, say, trb dev work) but enemy can drive up the cost substantially , with no guarantee of an increase on the other side of the balance to match it
asciilifeform: and yes, this only works with nodes that have cryptographically hard identity. and not with the syphilitic orgy familiar to classical trb users.
asciilifeform: (in trb, you also, recall, have the tx index db, and literally nobody knows what the dynamics are there)
asciilifeform: in classical trb, you have the 1MB/10min worstcase. but tightbounds are better.
asciilifeform: incidentally there is ye olde disk-is-full. and in future trbi with fixedwidth tx and block, node knows ~exactly when disk will fill, years in advance.
asciilifeform: (and with , i picture, much better detail than stock trb's log )
asciilifeform: there is no prioritization because of trb's fundamentally idiotic uniprocess socket handling. ( if there is no preemption - there can be no meaningful prioritization ! )
asciilifeform: and if you have a trb built with wires, it is 10min work (on client end), 10 seconds on the master.
asciilifeform: phf: most of today is re mircea_popescu showed a trb node that's been wedged, in a peculiar way, since july. but the l0g will still be there later.
asciilifeform: at this point i will recommend that -- when everyone has satisfied himself that 'wires' work -- every trb node oughta be wired to at least 1 known trb node
asciilifeform: though mircea_popescu's wedge is preventable, what trb really ought to do is start sending http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 to all peers, starting with any 'wires' if present, whenever it goes for >1hr without a new block
asciilifeform: trb's response to an orphan is 'tell me mybestheight+1th block DAMNIT'
mircea_popescu: is this no longer happening in trb ?
mircea_popescu: did the orphanage burner ruin trb 's chances of unwedging in this situation ?
mircea_popescu: yeah. and since you mention it, trb-i definitely needs a clarified push-or-pull model because the current system is the soul of unconsidered adhocery
asciilifeform: http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1364 and http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 are the only times a trb node asks for blocks explicitly from peer
mircea_popescu: no argument there ; you however may in turn recall that trb is by inheritance an utterly chtonian horror of heap allocation etc.
asciilifeform: mircea_popescu: you might recall that trb does not attempt to decode tx scripts (yes) when verifying block
mircea_popescu: asciilifeform no, i'll complain to you, because really there's no need trb logging be THIS RETARDED
asciilifeform: mircea_popescu: if not mega-seekrit, did this node peer with well-known trb nodes (e.g., mine ) ?
mircea_popescu: it'd be tremendously helpful for instance if the trb node had found it within its good graces TO FUCKING PUT TIMESTAMPS IN THE LOG.
asciilifeform: mircea_popescu: a block doesn't get to sit down in blk**** in trb unless its antecedents are present.
asciilifeform: pete_dushenski: mircea_popescu showed up with a bag of clues from a trb node that wedged some weeks ago. so now autopsy.
asciilifeform: incidentally trb probably ought to shit a sha512 of incoming block into the debug log
asciilifeform: trb's block push/pull mechanism is so retarded, that it is possible for a node to go for eons in a wedge, simply from never receiving the necessary unwedge blocks.
mircea_popescu: and inasmuch as node wasn't capable of extracting itself naturally, and it IS a trb node, this qualifies as successful attack against network, by and large.
asciilifeform: does it still, for instance, have orphanages ?! because that ain't really modern trb, in any real sense
mircea_popescu: was not, it's an older trb.
mircea_popescu: in other lulz, i found a trb node which is locked on block 419373 and dumps all blocks as unacceptable bastards
asciilifeform: but , upstack, when i think about trbi i go into 'bridge design' mode, where 'it gotta bear all of the tanks that could possibly physically fit, and then let's also assume that martians stack'em five layers deep '
asciilifeform: ~100% of asciilifeform's line of thought re 'trbi', from this, to the casks thing, etc., was only 'how to plug the leaks'
mircea_popescu: this item definitely counts for your grand list of trb-isms. on the strength of that, "computable", i ask no more.
mircea_popescu: trb-tits
asciilifeform: BingoBoingo: keep in mind, it's ~a possible~ trb-i, not ~the~... thing's quite certainly still in 'matrix mechanics' stage of life, and who knows, for how long.
asciilifeform: mircea_popescu: we had this thread, trb retains orphaned branches of any and every size, because it never goes back to remove anything from ~inside~ a blkxxxx.dat .
asciilifeform: ^ if anyone recalls the 'eatblock' thread -- i found that my blkxxxx.dat differed, in a handful of places, from mircea_popescu's, and yet again from every other trb node's.
mircea_popescu: it's not altogether clear to me how such a thing is an improvement over "just run your current trb through the future gossipd"
asciilifeform: the fixed-width-tx is a provable component of any long-term-sane trb-i. regardless of what other parts are included or excluded. without it, you get rapid rot.
asciilifeform: asciilifeform's aim was to consider gedankexperiment trb-i where this cock is turned around radially, at the miner. who, reaping most of the cake, ought to also absorb the cock.
asciilifeform: [BTC-dev] (CRACKPOTTERY) Notes re: one possible "TRB-I".
asciilifeform thinks 'holy fuck is the trb-i article looooong;' who will have the strength, to read this.
asciilifeform writing draft trb-i spec
asciilifeform: http://btcbase.org/log/2017-02-27#1619482 << right now, keeping a node is -ev for almost everyone who could be doing it. only oddballs with countereconomic motivation of one kind or another (e.g., trb experimenters) , plus miners themselves, plus serious txers ( e.g., mircea_popescu ) have a desire to do it. there are not so many of these. it is rather like relying on entirely on coprophagics for your sewage disposal needs.
asciilifeform: unless i misunderstand trinque , he pictured a trbi where miners would advertise 'hi, i'ma miner, and i'd like some tx of yours'
asciilifeform: trinque: say we stick to the trb-i thread. gotta specify what specifically about your concept of trbi, that would remove the incentive for miner secrecy that exists in classical bitcoin.
asciilifeform: trinque: this is doable right now, you can comment out the mempool in trb...
mircea_popescu: but the correct trb-i might just as well end up this situation where block reward is 1mn bitcoin, and it dies within 1mn blocks. so all mining does is produce ~ a lease ~ on a chunk of bitcoin. and the value of old bitcoin is monotonically decreasing over their lifetime.
asciilifeform: mircea_popescu: just to make it absolutely clear, i don't see a long-term future for satoshi's turd. all of my work on trb is to be regarded in same light as the neutron-absorbing armour on 1970s sov tanks -- something with which to prolong the life of the crew ~slightly~ so that it can drive over freshly-nuked ground and last a few hours of shootout.
asciilifeform: to revisit much further upstack, to http://btcbase.org/log/2015-02-14#1018732 ( via mircea_popescu's latest article ) -- consider a 'trb-i' where a tx carries proof of work, and is likewise mined as is the block
mircea_popescu: asciilifeform yes trb does reindex.
asciilifeform: i suppose one way to rebuild the index using existing mainline trb would be to nuke the .bitcoin dir entirely, and refeed the node via 'eatblock'.
asciilifeform: trb does not have a knob for 'reindex and make sure blkxxxx matches the index'.
asciilifeform: now you need extra logic in trb per se, and this is no longer 'cheap perl hack'.
asciilifeform: well not entire fs, but every file touched by trb
asciilifeform: very concretely: all enemy has to do, to gum up a trb node, is to repeatedly request blocks from 0 .. current, randomly, and switch ips as needed
asciilifeform: (a trb-i item )
asciilifeform: btw i suspect that 'tx must include a micro libation to the gods' -- i.e. a leak -- is a necessary component of 'hard vacuum', 0socialism trbi as discussed earlier
asciilifeform: while we're doing trb-i : in addition to 'tx is 1024 bytes, and block is 1024 tx' , consider another item: 'block MUST contain 1024 valid tx'
mircea_popescu: absent a good or at least workable breakthrough in this vein, there's no strong technological incentive to move to trb-i
mircea_popescu: idiot example #2 : a trb which allows txn to be blocked by others than their issuers is ALSO a "way to do things" which doesn't in fact work, and therefore, exactly equivalent to the peter todd & prb idiots item
mircea_popescu: yes, but the idea is to not expand the hipster doofus design principles to trb-i
mircea_popescu: the g has a decent debottler built in ; the trb-i does not, and needs a few.
asciilifeform: in given trb-i scheme, a block either exists on disk -- or does not
asciilifeform: locking problems (gotta add tx to index, in current trb, as aggregate -- but the only way to do that is to stop the world! like complete idiot -- every time there is a new block, to prevent situation where there is a partially indexed block available to incoming mempool tx verifier) disappear.
asciilifeform: in either hypothetical trb-i -- you no longer need a db. any db.
asciilifeform: to clarify -- in my mind, a 'trb-i' ~must~ be capable of checking validity of tx at wire speed (i.e. at the speed it is physically capable of receiving them) on reasonable iron.
mircea_popescu: trb-i, yes?
asciilifeform: trb node is, for instance, continuously engaged in the sin of 'something to allcomers'.
asciilifeform: ben_vulpes: pretty idle lately , actually, trb is a procrastinatory escape from the hardstuff
mircea_popescu: anyway, asciilifeform, you should prolly publish a codebase adnotated with time profiles. trb-454523 ; trb-454520 etc.
asciilifeform: would seem that these are a type of pseudonode / misc. attacker, that comes in two varieties, one aimed at recent prb (majority), the other -- more trb / old-prb - flavoured.
asciilifeform: in other lulz, there is a large population of nodes reporting 'version message: version 60000, blocks=350000' for all eternity (typically they auto-disconnect when discovering trb ver.) . anyone know who they belong to, and wtf ?
asciilifeform: (stock trb will happily drop ~anyone~ on the floor, for dozen different reasons, incl. 'we used him for too long')
asciilifeform: unbitflippable direct pipe to large trb node.
asciilifeform: unrelatedly, system of two 'wired' trb nodes appears to have marked resistance to 'blackhole'.
asciilifeform: adlai: any time you feel like doing something useful -- no shortage of items. there is, for instance, a trb knob direly needing testing, http://therealbitcoin.org/ml/btc-dev/2017-February/000251.html
asciilifeform: ( if you recall , that was when we had a trb node, offline, eat the complete chain to date from disk, with timer and valgrind going )
asciilifeform: to what else would you have trb 'respond as they expect', PeterL ? bloom filter? segshitness?
asciilifeform: classical trb did not have a nondisconnectable marker for peers; would not connect to localhost; and deprioritized non-8333 ports to dead-last order. 'wires' fixes this.
asciilifeform: in other noose, http://wotpaste.cascadianhacker.com/pastes/jJ7iS/?raw=true << on a traditional (zoolag) trb node. i never once saw these in past log readings, and now they are quite common.
asciilifeform: considering that it cuts off stock trb -- it is surprising that it was at any point caught up.
asciilifeform: (4) is unfortunately ultimately rubbish, it is really the single-threaded, polled socket handler of trb that is ultimately morally responsible.
asciilifeform: 1. 'blackhole.' 2. tcpdump on two blackholed trb nodes. multitude of peers emitting 'ping, ping, ping...' and soaking up sockets. 3. hypothesis: killing socket hoggers will dissolve blackhole. 4. 'socket-hogging prb is responsible for blackhole condition'
asciilifeform: to briefly revisit upstack: in case this was unclear to anyone: goodbye-pingers ~breaks connectivity with stock trb~ and ought to be considered experimental/dangerous . it is not yet clear to me that the pill is an improvement over the disease.
asciilifeform: because as it is, trb nodes (such as zoolag) are getting the hammer.
asciilifeform: (or rather, no longer emits pings. trb nodes emitting pings -- still banhammered)
asciilifeform: this one, lel, no longer bans trb nodes...
asciilifeform: in other lulz, 104.199.165.17 << google spider . now attempts to connect to trb nodez.
asciilifeform: (see the logs of any operating trb node)
asciilifeform: i.e. 'trb-i'
asciilifeform: right now this is not even a very interesting wtf. it may however become interesting if a miner decides to sit down on trb island.
asciilifeform: my concern is not that there is a boojum in 454074. but that the thin red line connecting my trb nodez to miners are -- apparently -- veeeery thin
mircea_popescu: asciilifeform> to continue: what portion of cpu time is spent verifying ultimately invalid blocks? <<< yes, yes and yes, altogether a proper STATs module should very much be part of stock trb, and very helpful if it were.
asciilifeform: or, how much time does trb node spend rejecting crapolade from same idiots again and again
mircea_popescu: originally, miner code got split off the main satoshi base sometime in 2011. there was a lot of back and forth between pre-trb prb node code and the node code miners used, but not that much in the past few years.
mircea_popescu: at that point, the writhing horror (which you think of as prb) had about 10x as many loc as trb does ; by now it's 100x.
mircea_popescu: asciilifeform it drops them. and i am pretty clearly remembering we talking about this in the early days of trb and foundation
asciilifeform: box falls behind, loses peers, begins to sink into classical blackhole behaviour (as it gets dropped by everybody, including fellow trb nodes)
asciilifeform: so they see trb set to, e.g., 99999 (as mine, for instance, are) and goes ping,ping,ping,motherfucker,ping,ping,whywontchapong
asciilifeform: ada proggy, speaks the protocol as defined by trb; but does not attempt to verify blocks, instead uses its 'horse' (trb node it rides) as an oracle
asciilifeform has been experimenting with a proggy that 'rides' a trb node, and takes over all comms with outside world
asciilifeform: and yes, i revved up a fully mod6tronic trb to have what to patch against, my working copies are quite dated
asciilifeform: considering that this builds toolchain, gcc, linux kernel, busybox userland (currently unused), then trb deps, and then trb...
asciilifeform reports a successful replication of mod6's recipe http://thebitcoin.foundation/trb-howto.html , 'offline' variant, using his vtron etc. took exactly 40 minutes from the instance of making an empty dir to do it in, to having <5MB finished binary in my hands.
asciilifeform: http://btcbase.org/log/2017-02-19#1615717 << i gotta wonder what the folx without 1+ working trb node, think they are doing.
asciilifeform: in other lulz, heathendom https://bitnodes.21.co/nodes/?q=/therealbitcoin.org:0.9.99.99 sees 9 trb nodez.
mircea_popescu: i am not against trb having a debugger
asciilifeform: to revisit upstack, ftr trb still does not have a tx debugger. when, e.g., mircea_popescu, asks me 'have you seen tx T', all i have is to grep the log barf
asciilifeform: mircea_popescu: consider publishing your tx debugger as a trb patch ? (the thing that lets mircea_popescu answer questions like 'where is ea58f22fe5bbb4f42edb8be90a37f98b57af12007f7620f7ab94111a06ff3ebb ?' )
mircea_popescu: i'm not entirely sure, but afaik trb still imports original satoshi assumptive boneheadedness in that it will not consider tx updating its own wallet which it didn't issue itself.
mircea_popescu: i don't think trb updates your wallet balance in this case. it updates it when it sends something, it doesn't rescan for doublespends.
asciilifeform: what you want is a box that ~only~ talks to a handful of trb nodes. that you operate.
asciilifeform: ben_vulpes: didja try the scheme where your node only talks to trb nodes ?
asciilifeform: different patch sets will give trb with DEEPLY differing behaviours.
asciilifeform: hanbot: (and everyone else reporting a suboptimally-behaving trb node) -- plz consider stating the vpatch-set
asciilifeform: ( recall when i suggested to distribute trb+buildroot+gcc et al. on a cdrom. )
asciilifeform: incidentally i realized that, sadly, trb will need a (simple) patch in order to link via 'g'. from simple fact that, by default, it does not like to connect to 127.0.0.1:weirdport
mircea_popescu: http://btcbase.org/log/2017-02-08#1612495 << if your trb node is on solid hardware might as well add it to the list of nodes ; otherwise there's an ample swath of thingd to do, depends what your inclination is. i suggested looking into mimisbrunnr in the context of http://btcbase.org/log/2017-01-29#1609460
asciilifeform: anyone other than thestringpuller has trb node that can't hear dulap ?
mircea_popescu: http://btcbase.org/log/2017-02-03#1611095 << this is not actually true. trb wallet encryptor is pretty strong. not ideal, but there's no actual cause of worry if you lose an encrypted bitcoi nwallet (still, doesn't encrypt metadata, has many other warts discussed in http://trilema.com/2016/the-ideal-bitcoin-wallet/ ) ; i wouldn't say same re gpg keyring.
asciilifeform: http://btcbase.org/log/2017-02-03#1611084 << it is approximately as useful as trb's wallet encrypter, and for the same reason
asciilifeform: it is not actually very enlightening to a student of trb, because various subsystems were replaced wholesale.
asciilifeform: as for mempool messages, we have , in current trb :
asciilifeform: i can trivially cause it on my box by throwing, e.g., FUCKGOATS genesis, into trb dir...
asciilifeform: imho it may or may not make sense to make a tool just for trb. just as raising most ww2 sunken submarines is not +ev, only the ones full of nazi gold.
asciilifeform: the only cpp in my pogo build was trb.
asciilifeform: trb is the only one i know of first-hand
asciilifeform: btw mircea_popescu's list of Open Problemz imho should include (~usable~, unlike solrodar's) trb flow-graph
mircea_popescu: use v to set up a trb node yes.
mircea_popescu: ah. well, from a simple "cs competency" perspective, doing a trb build first is very good practice. i'll familiarize you with what's here a minimal bar of qualification and anywhere else above the reach of graduate students somehow. and it'll show you the power of the tools and the quality of the engineering.
mircea_popescu: do you understand the bitcoin end of things ? are you running a client ? ever got a v-build of trb to run for instance ?
asciilifeform: again, if davout breaks his trb, and signs off on a b0rk3d proggy, it does not 'pick my pocket or break my leg', mine will still work.
asciilifeform: and in fact recall, i asked for trb, because i wanted The B00k
asciilifeform: fwiw i do not hold to 'trb 4evah!'

Random(trilema) | Download hourly DB snapshot | Get Source Code