mircea_popescu: you can just take stock trb, operate on it, and place it so it only connects to operator-specified trb nodes.
davout: it would have allowed some level of split, but anyway, this particular idea is dead since trb doesn't have this in-memory data structure
mircea_popescu: this'd be wallet-trb.
mircea_popescu: node-trb.
davout: i thought trb was keeping them in ram already
davout: in essence, that's already what trb does
mircea_popescu: trb too, for now, i guess.
davout: you mean trb?
davout: 2. the way the existing trb wallet currently works, mainly the automatic utxo selection
davout: found out that i in fact hallucinated the existence of this index, which may or may not have been added later on to prb, but was absent from trb
davout: i thought i'd find an in-memory UTXO index, which i didn't. appears to me like trb will have to keep some sort of "watched addresses list" after all, or that such an index will have to be bolted in somehow
davout: so i did some reading re the wallet separation thing and ended up realizing i had an incorrect idea about trb's internals
trinque: also, speaking of wot.deedbot.org (and specifically the generated SVGs) and http://btcbase.org/log/2015-07-04#1186410 (which I have patches in hand to fix the build) I may have something of a usable trb map in the near future.
shinohai: I still have a copy in archives, but haven't tinkered with it much. jhvh1 and trb keep me pretty busy.
Framedragger: Reuel: just fyi, and it's only my humble opinion, but you don't need the context of the whole trb to do the symlink experiment. from what i took of it, it's a matter of testing how various filesystems (probably starting off with ext4) can manage with (very) large numbers of nodes and large numbers of links to nodes. how seek times increase with those numbers of links to links, etc. (as an fs overhead, on top of hdd/sdd).
Reuel: however life is getting in the way at the moment, and I don't have time to go through all the TRB code, which is probably a must to understand the context of the experiment
asciilifeform: no one will ever confuse anything we might recognize as trb for any artifact from the distant Planet of Sane People.
a111: Logged on 2017-03-04 17:53 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: 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)
ben_vulpes: subject of trbi, did i miss a way for a parent to cancel a cask ask shy of fibbing?
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 )
ben_vulpes: this is a desirable situation? that trb logging include timestamps and shit into log that which came from whom?
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.
ben_vulpes: 0036.dat also implies a trb .dat file, not a dumpblocked file? happy to crack it open and see though
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
PeterL: while we are talking about things to stick in TRB-I, how about lowering the block size by an order of magnitude or so?
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 '
a111: Logged on 2017-02-27 16:56 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: ~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.
mod6: yeah, trying to keep up with all these posts. just started this one on "possible trb-i"
mod6: <+BingoBoingo> <mircea_popescu> trb-tits << I thought that was shinohai's fork << :D
BingoBoingo: <mircea_popescu> trb-tits << I thought that was shinohai's fork
mircea_popescu: trb-tits
BingoBoingo: asciilifeform: In my mind trb-i is discussion piece. Ideal may be impossible. trb-i may end up being way to consider idea for trb-b which suceeds trb-a (a is for arse)
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.
BingoBoingo: Oh the Trump flensing knife lulz come out tonight, while still digesting trb-i theory. What a time to be live!
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.
jurov: and can trb live with terabyte tx index at all?
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 )
a111: Logged on 2016-12-29 23:20 asciilifeform: type2 ( pete_dushenski's ) is the garden variety shitflood. which is sometimes solved by ip ban, but only in the case of 'shrapnel addressed to occupant', i.e. idiot prb nodes wildly spamming crapolade, and not in the 'bullet with your name on it' case, where somebody actually has a sybil constellation drowning your trb node in liquishit, with no SINGLE ip misbehaving in any way
deedbot: http://trilema.com/2017/trb-i-addressing-scheme-proposal/ << Trilema - TRB-I Addressing Scheme Proposal
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'
a111: Logged on 2017-01-17 00:21 asciilifeform: to possibly squeeze something useful from thread: as i understand, a lamport-based 'trb-i' ~could~ run on z80.
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
jurov: https://bitnodes.21.co/nodes/?q=Slovakia i finally put up permanent trb node (it's the syncing one), but have nfi about the other two
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 ?
lobbes: http://btcbase.org/log/2016-03-03#1421109 << btw, thank you for this, alf. I will be embarking on my own gentoo quest soon to finally stand up a trb node
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.
shinohai likes to minagine this `wires` patch as G for trb
a111: Logged on 2016-01-20 02:05 asciilifeform: presently trb does not have this sane behaviour
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.
BingoBoingo: asciilifeform: Bastard 0.7 ish node corrected will patch trb nodes at convenient time, tyvm
ben_vulpes: it should be doable to 'getpeers' from the nodes from which a trb gets a block and then attempt to traverse upstream, no?
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
hanbot: http://btcbase.org/log/2017-02-19#1615687 << fwiw, receiving wallet does see amt sent. meanwhile trb restarted with -rescan shows same balance as before, which we now realize *had changed* following transaction just...not by amt sent. to wit, listtransactions sees original balance, sees correct sent amt with fee, nevertheless balance via getinfo has mystery-difference. which shows as a negative, and only value, via listaccounts.
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.
hanbot: test tx via trb using sendtoaddress fails to send diddly squat, meanwhile @ blockchain.info: transaction rejected by our node. Reason:Script resulted in a non-true stack: []
thestringpuller: asciilifeform: would i have to modify how OpenSSL is initialized in order to use FUCKGOATS with TRB? >> https://wiki.openssl.org/index.php/Random_Numbers#Hardware
a111: Logged on 2017-02-16 02:49 hanbot: what's the proper name to ascribe to this super fun phenomenon wherein trb node happily catches up on blocks until 99.x% and then drops connections and stops seeing new blocks after <10mins?
a111: Logged on 2017-01-13 02:53 asciilifeform: http://btcbase.org/log/2017-01-12#1602003 << we do not, afaik, presently have a knob in trb that would enable the 'at you' part of this.
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 ?
ben_vulpes: so in light of the triviality with which the TRB node to which mimisbrunnr talks is taken out by even moderately determined actors, i'm considering taking the whole thing down until i have a more robust data collector system in place.
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
BingoBoingo: Coding patch to simply say "no" to compact blocks and restore TRB/PRB communion would likely be trivial, BUT setting that precedent is impossibru
hanbot: what's the proper name to ascribe to this super fun phenomenon wherein trb node happily catches up on blocks until 99.x% and then drops connections and stops seeing new blocks after <10mins?
a111: Logged on 2017-02-08 20:46 Reuel: mircea_popescu, i am geting blocks so i guess i built TRB, what would you suggest i do next? you mentioned mimisbrunnr, looking at that now, anything practical I could do except read?
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
Reuel: mircea_popescu, i am geting blocks so i guess i built TRB, what would you suggest i do next? you mentioned mimisbrunnr, looking at that now, anything practical I could do except read?
shinohai: http://thebitcoin.foundation/trb-howto.html <<< is pretty self explanatory ... phf also has a nice source viewer which is helpful for reading the code.
Reuel: does trb have the bitcoin-cli rpc stuff like the other implementation?
shinohai: Reuel: I'd say Gentoo myself, though trb *has* built countless times for me on Ubuntu/Debian
Reuel: When I am looking at the TRB site seals, I see more than one for each patch, does that mean code has been reviewed?
asciilifeform: anyone other than thestringpuller has trb node that can't hear dulap ?
thestringpuller: as of current looks like there are no TRB nodes responding
shinohai: Strange wheezy won't build trb ... I did it < month ago without issue.
thestringpuller: mod6: wheezy doesn't want to build TRB anymore. ping me if you have a specific image that you recommend from the wheezy era
nicknaem: on another machine now just wanted to get the keys as described in http://thebitcoin.foundation/trb-howto.html
pete_dushenski: trb has 'help' yes ?
pete_dushenski: my own recent efforts at coding are going less productively. trying to implement polarbeard's 'getpeerinfo' patch and can't even get trb to show the option on the help menu nevermind implement the functionality
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.
a111: Logged on 2017-02-03 15:26 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: http://btcbase.org/log/2017-02-03#1611084 << it is approximately as useful as trb's wallet encrypter, and for the same reason
pete_dushenski , very late to the party, wishes for getpeerinfo in trb
ben_vulpes: pete_dushenski: the most i can imagine you'll learn about the differences between prb and trb without reading the source is that the latter doesn't have a gui
asciilifeform: it is not actually very enlightening to a student of trb, because various subsystems were replaced wholesale.
pete_dushenski: i have no such software in operation atm. though i may fire one up just to see what i can learn about the cuts trb ultimately made.
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...
mod6: I need to get the ball rolling for something like that with TRB as well.
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 ?
a111: Logged on 2017-01-27 19:32 ben_vulpes: davout: reference miner is still in trb bin.
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!'
asciilifeform: which is why the clock on replacing trb, does run.
asciilifeform: my objection is not 'davout Broke Trb oh noez!!' but to the thought process that might lead an otherwise literate d00d to contemplate a 'reference' that lacks vital organs as a valid thing
asciilifeform: ditto trb-minus-mempool.
asciilifeform: ditto trb-minus-any-miner.
asciilifeform: but to rewind: i do not object to davout mutilating his own personal trb however he likes. however i do object to calling a trb-minus-any-wallet a 'reference implementation'.
asciilifeform: btw since folx are itchy to snippety-snip, i will note, there is actual dead code in trb
asciilifeform: in point of fact if trb knew how to eat raw tx, you have the knob, neh?
asciilifeform: i asked very specific question. say davout makes a wallet-less trb. and for some reason we all embrace it and roll it into each his own personal vtree.
trinque: the wallet merely generates inputs trb will validate or not independently of it
davout: asciilifeform: trb is about keeping the core, prb is about "moar featurez"
asciilifeform: what i would like to do in this thread, is to ask folx to stop and think for half a minute about what differentiates trb from prb.
ben_vulpes: davout: reference miner is still in trb bin.
ben_vulpes: davout: what /currently/ compiles as the single binary "trb"
davout: i'm not really sure whether transaction signature itself should stay in trb or be extracted out
ben_vulpes: i am still not sold on moving the wallet outside of what compiles as "trb"
davout: asciilifeform: if trb provides sane endpoints the wallet can be written in whatever floats anyone's boat
asciilifeform: in fact, until we nailed down the dependencies all the way down to the kernel and gcc, it was possible to argue that trb does not define bitcoin.
asciilifeform: the even faint implication that i ought to so much as consider heathen nontrb wallets.
asciilifeform: but to lose functionality, however uncommonly needed, that does exactly 0 harm, and the loss of which reduces by no amount the labour of a trb code reader, is at best a snore.
davout: if you ~must~ verify one of those sigs you pull up a trb that can ~fin~
davout: maybe we can have trb-classic then trollface.jpg
trinque: there are goals at odds here. to fix the nightmare that is current trb, gotta start slashing til you have something that's able to be comprehended
trinque: "nothing but this particular arrangement of driftwood counts as actual reference trb"
davout: asciilifeform: the trb tree has a "continuity-preserving" mission, not "current trb official version"
asciilifeform: davout: yes, they could 'rebuild historical trb' but imho if this is a kind of thing that ever becomes necessary, trb will have failed in its continuity-preserving mission.
davout: asciilifeform: archaeologists can build a verifymessage-capable trb, couldn't they?
asciilifeform: trinque: trb already exists in multiple branches, such is the nature of vtronics.
trinque: I don't see that it'd be a terrible sin to have multiple branches descending from current trb
davout: lighter trb?
thestringpuller: s/with bitcoin/with trb*
thestringpuller: is there a way to scrape the UTXO set in TRB or do you have to do that manually as of now?
asciilifeform: snipping old wallet is a trivial patch, i suspect that any and each of trb folx could re-create it in half hour
asciilifeform: if , using your trb, i cannot transact ?
asciilifeform: mircea_popescu had a pretty good imho description of the necessary cutting-apart of trb
ben_vulpes: davout: why would you even consider releasing a patch that leaves trb unable to cook and transmit transactions? keep it on your table where it's useful to you.
davout: asciilifeform: can use same openssl as trb
ben_vulpes: davout: trb cannot exist in a state where "user must supply code for x"
asciilifeform: or is the plan to create (why???) a quite-useless castrato-trb.
davout: asciilifeform: to me trb just has to provide "return txouts spendable by arbitrary set of addresses", "add this transaction to mempool"
davout: so with the eventual goal of cleanly amputating the wallet off of TRB I'm kind of wondering what the best approach is here,
asciilifeform: in turn it is also why i have an interest in a hypothetical nonbignumtronic (i.e. lamportronic) 'trb-i'.
asciilifeform: mircea_popescu: 3.x linux kernel; gcc 4.9; musltronic toolchain; emacs 24; trb; v; gpg 1.4+rngpatch+timingleakpatch .
asciilifeform: this is sorta why i wanted to put out trb, frozen gcc, linux, etc. on a ~pressed aluminum~ cd
mircea_popescu: asciilifeform ben_vulpes and davout are evidently struggling with the trb ; so was mod6 before we fucked up his week with v stuff ; diana_coman is purging idiocy out of eulora and so on. plenty of people.
asciilifeform: and trb-genesis let it be CLEARLY and PERMANENTLY marked as not-child-of-mine, for each of the signatories.
asciilifeform: but Framedragger has a larger and imho relevant point, the ecc in trb is part of the world-as-we-found-it
asciilifeform: trinque: a good chunk of the appeal, i dare say, of trb, is the ~pedigree~
asciilifeform: iirc mircea_popescu still does not use trb to touch actual megacoinz
asciilifeform: is trb in use 'in production' somewhere ?
asciilifeform: (my original aim with tinyscheme was strictly to weld an interactive debugger into own trbtron.)