Results 1 ... 250 found in trilema for 'trb from:BingoBoingo from:asciilifeform'
| →
BingoBoingo: !Qlater tell mod6 If you are still updating the node list on the trb site I've got: 143.202.160.10 in Costa Rica, 88.80.148.58 in Bulgaria, 192.151.158.26 in Kansas, and 205.134.172.4 in AlfRack running and sync'd. First three running 99999 version number, last running 70001 version number.
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.
BingoBoingo: asciilifeform: It came out in duffel run. Was on tiny box I flew in that held first pizarro www and dns server along with first pizarro trb node
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 !!
BingoBoingo: I'm suspecting a lot of nodes on the intermediate PRB version numbers 0.8, 0.9, etc before peer-to-peer pki-ism are falling enough that we may have few bridges allowing communication between prb and 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.
BingoBoingo: And it looks like we have consecutive days of TRB constipation 592597 has yet to enter the canon
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.
BingoBoingo: After a long stretch of not needing to give a day or two and seeing the whole trb-iverse visible from my chair stuck on the same block, I figure why not try to forcefeed the problem block
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: girlattorney: 'discard excess' in trb algo is ANYTHING received when its antecedent is absent.
BingoBoingo: <girlattorney> but i could argue with this: when i do bootstrap a core node, it actually get fed from other core nodes << During initial sync trb wants to receive blocks in order while core will intentionally spray blocks out of order
BingoBoingo: Playing with the version string on a TRB node is the fastest and simplest way to change the sorts of peers your node encounters in the wild
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.
asciilifeform: corollary to this q : how would a 'trb ebuild' differ from the trb vtree as it stands ?
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
BingoBoingo: The TRB 3-6 week sync (CPU and disk bound) is a strictly linear, no exceptions to verification affair
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: 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)
asciilifeform: this was a 2015 find. after which asciilifeform immediately proceeded to get glibc the hell out of trb.
asciilifeform: ( and asciilifeform -- trb ) etc
BingoBoingo: !!rate mod6 4 TRB, Pizarro, testing of things
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 )
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
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 ?
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)
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.
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.. )
asciilifeform: mats: i assume you had most recent mainline trb (i.e. with 'aggression' ) ?
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.
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
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.
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'
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 ?
BingoBoingo: <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 << I run a bitcoind linked against libressl 2.5.5 and so far it hasn't forked
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
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
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 ??
|
→