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.
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
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.'
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.
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!
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!'