Results 1 ... 32 for 'trb cement'...

Results 1 ... 32 found in asciilifeform for 'trb cement'

asciilifeform: still oughta make cgra's suggested corrections before adding to flagship vtree.

whaack: so i'm about to build trb up to asciilifeform's cement patch to start the sync process in my new rack in NZ, and it's a headache to run around different blogs collecting various vpatches, i think that my next project will be a copy of http://btcbase.org/patches , except with a hopper . i wonder if anyone thinks that perhaps the search-all-blogs for various vpatches is a feature and not a bug,

cgra: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-26#1080994 << i had the same feeling from the earlier usage, but see for example my latest, look for 'storycontent', and it's pretty alright wysiwyg output

dulapbot: Logged on 2021-11-15 21:29:41 asciilifeform: a properly-adaized replacement-trb (i.e. with ZERO traces of derpcoad and demonstrably bug-free) would be what one could call 'permanent software'

scoopbot: New article on cgra's: TRB 'Cement' Draft Review

asciilifeform: but asciilifeform would rather leave the decision of 'cement or not' to indiv. operator, rather than try to make it hardcoded piece of trb.

asciilifeform: cementism is a fundamentally unprincipled departure from basic premise of trb, where 'mechanism is offered whatever liquishit by whole planet, but will find longest chain per simple rules'

asciilifeform: for that matter there's a primitive proto-cement in classical trb already.

asciilifeform: 'not quite bitcoin', asciilifeform's demo of adaistic ab-initio mechanisms for hypothetical replacement of trb

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

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

scoopbot: New article on Loper OS: DRAFT Full "Cement" Support for TRB.

cgra: asciilifeform: re cement getdata algo, wanna point out that in theory there's also a risk of sendbuffer flooding some trb peer, especially with a lower-than-default sendbuffersize, if peer's upload is slow, and/or peer stuck at the same time doing smth else

dulapbot: Logged on 2022-02-17 09:52:45 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079578 << prolly won't surprise cgra that asciilifeform concluded that doing ~anything~ in parallel in trb is ~impossible w/out removing locks and potentially opening gates of hell. asciilifeform's draft 'usecement' is 100% serial, asks for 1 block at a time (and wastefully, 'getdata' to each connected peer, thinking atm how to reduce the bw guzzling)

whaack: also in this case the cement logic belongs in the shit-filterer, not in trb itself

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2022-02-17#1079578 << prolly won't surprise cgra that asciilifeform concluded that doing ~anything~ in parallel in trb is ~impossible w/out removing locks and potentially opening gates of hell. asciilifeform's draft 'usecement' is 100% serial, asks for 1 block at a time (and wastefully, 'getdata' to each connected peer, thinking atm how to reduce the bw guzzling)

scoopbot: New article on Loper OS: A "Cement"-Maker for TRB.

dulapbot: (therealbitcoin) 2020-08-30 asciilifeform: http://logs.nosuchlabs.com/log/therealbitcoin/2020-08-30#1001100 << imho 'cement' would be useful if implemented compactly; then could feed a node <100MB signed list of hashes and it'll download correct blox through N from the net. but indeed 'less mutilation is best' imho when comes to trb; and if thinking about it, ANY trb node that aint synced to ~current height, will in fact refuse to relay most tx (and will be mostly busy

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-11-16#1066298 << iirc this aint even the 1st purported 'compatible client from scratch'. they aint necessarily uninteresting, but they aint, for fundamental reasons, plug-in replacements for trb, even if on the surface 100% correct somehow

asciilifeform: a properly-adaized replacement-trb (i.e. with ZERO traces of derpcoad and demonstrably bug-free) would be what one could call 'permanent software'

punkman: should a trb replacement include features needed for mining?

asciilifeform: as far as asciilifeform's concerned, until can replace it & the rest w/ pest nets, #a will serve as the interim replacement for #trb as well.

dulapbot: Logged on 2021-09-09 13:41:05 asciilifeform: asciilifeform has two uses for ffa -- general-purpose sign/verify suitable for use w/ generalized vtron ; and for the ecdsa numerics in ada trb replacement.

asciilifeform: asciilifeform has two uses for ffa -- general-purpose sign/verify suitable for use w/ generalized vtron ; and for the ecdsa numerics in ada trb replacement.

dulapbot: Logged on 2021-08-31 15:46:22 asciilifeform: asciilifeform would happily produce e.g. ada replacement for trb. but for whom? instead currently fixing bugs in a vast legacy [censored] for [outfit no one ever heard of], and similar.

asciilifeform: asciilifeform would happily produce e.g. ada replacement for trb. but for whom? instead currently fixing bugs in a vast legacy [censored] for [outfit no one ever heard of], and similar.

asciilifeform: additionally, trb is imho valuable for its original, per asciilifeform , purpose -- to serve as gold standard ref for work on replacement client.

asciilifeform: imho optional 'cement' input (i.e. of known-good list of block hashes) would be the sane thing for trb sync.

asciilifeform: likewise must note, if you want to be able to verify received 'cemented' block out of order and/or in parallel, would have to actually make the db thread-safe. which presently it aint (nuffin in trb is thread-safe, there are just about 'over 9000' locks in there, which make the thing effectively single-threaded)