asciilifeform: which is why you'll often find trb-related tcp pipes randomly RST'd, and the like.
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'
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
asciilifeform: mircea_popescu: you might recall that trb does not attempt to decode tx scripts (yes) when verifying block
asciilifeform: mircea_popescu: if not mega-seekrit, did this node peer with well-known trb nodes (e.g., mine ) ?
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.
asciilifeform: does it still, for instance, have orphanages ?! because that ain't really modern trb, in any real sense
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'
BingoBoingo: <mircea_popescu> trb-tits << I thought that was shinohai's fork
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.
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...
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
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'
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.
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
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
BingoBoingo: asciilifeform: Bastard 0.7 ish node corrected will patch trb nodes at convenient time, tyvm
asciilifeform: or, how much time does trb node spend rejecting crapolade from same idiots again and again
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.
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 ?' )
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
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
asciilifeform: anyone other than thestringpuller has trb node that can't hear dulap ?
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
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.
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.
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.
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.
asciilifeform: trinque: trb already exists in multiple branches, such is the nature of vtronics.
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
asciilifeform: or is the plan to create (why???) a quite-useless castrato-trb.
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
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.)
asciilifeform: trinque: consider the trb-genesis as a successful use case of the thing i am asking for.
asciilifeform: why does trb-genesis get special treatment in mircea_popescu's scheme ?
asciilifeform: note that we did ~same thing for trb genesis.
asciilifeform: btw mircea_popescu's criticism of shiva-genesis was 100% deserved, it ~does in fact~ logically depend on trb, but did not indicate said dependence vtronically
asciilifeform: makes trb look good.
asciilifeform: emacs, gcc4.9+gnat, build tools, trb, kernel.
asciilifeform: trinque: pretty strange, because threads work fine in musltronic trb
asciilifeform: to possibly squeeze something useful from thread: as i understand, a lamport-based 'trb-i' ~could~ run on z80.
asciilifeform: which part << 'a workstation is, minimally, something that can build trb and keep up with blocks'
asciilifeform: (there ~is~ a certain bottom floor to 'workstation', defined imho by ability to build&run trb. but it is lower than '4GHz')
asciilifeform: the 1 place i must disagree is 'idiocy outside does not matter to adult. the sweat i put in to remove the fleas from trb, but also from many other things so that i could even attempt that work, was quite real.
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 off to trb room to verify this statement. and then to bed.
asciilifeform: per trb.
asciilifeform: mircea_popescu: the 'lisp trb' is sussman's 'scheme83' chip.
asciilifeform: how or why, for instance, it took most of a year to arrive at a 100% static and embeddable trb
asciilifeform: (y'know, where i stuffed bootable linux kernel + userland + trb into 5MB with 0 drepperola or poetteringola)
asciilifeform: 'There is no information available on the XFree86 home page on becoming an XFree86 developer. Information for new developers consists of the mention of a couple of mailing list addresses in the README document included in the XFree86 4.3 release.' << picture how d00d would react to meeting trb
asciilifeform: i did say 'trb worx great with trad diff' neh
asciilifeform: trb will probably remain in trad style 4evar
BingoBoingo: And they work off of some poor folk voucher system instead of actual trb
asciilifeform: stock trb mempool
asciilifeform: in the case of candidate-block and candidate-mempooltx queue receiver (from outside the walls), mircea_popescu proposes to throw out even the weak logic for banning obvious crapola that we have today in trb?
asciilifeform: (trb.b, presumably, polls..?)
asciilifeform: and not only of std::map in the abstract, but of the same set of maps everywhere in trb, simultaneously, and at the same time with the pestilential global locks
asciilifeform: davout, ben_vulpes , et al : it is also tricky to properly rule out the situation where split-trb node behaves like a 'split-brain patient', and external observer gets contradictory answers from it to some possible question
asciilifeform: trb miner is mircea_popescu's 'fleet in being'
asciilifeform: (a result where there is ~no~ miner available, i exclude from consideration because it pisses on the R in 'trb')
asciilifeform: though what i pictured is that trb can finally produce the motherfucking ~book~ and it will be possible to start rewrite...
asciilifeform: as, e.g., trb itself.
asciilifeform: mircea_popescu: i can think of one (nonfatal, but quite unpleasant) headache: without a less-idiotic replacement for gnudiff, the resulting cut-trb becomes very difficult to pedigree to trad-trb . sorta like the problem with the tabs/spaces cleanup proposed by mircea_popescu last year
asciilifeform: (the 'sanity proxy', if you will, for trb)
asciilifeform: 1 process, in which all threads share (quite catastrophically, as readers of trb ml will know) the heap.
asciilifeform: i dun recall anyone ever suggesting that trb be distributed as exe...
asciilifeform: and i was quite surprised when starting trb and noticing that it was absent there.
asciilifeform: and no, turning python into a trb dependency is not sane.
asciilifeform: (spoiler: it comes from your system clock +/- the voodoo delta that trb comes up with using peers)
asciilifeform: ergo no trb node will ever reject a tx for reasons pertaining to 'locktime' garbage.
asciilifeform: and in any sane future trb.
asciilifeform: even in the oldest trb.
asciilifeform: my contention is that a trb with entirely removed unspent-selector is not usable-naked.
asciilifeform: mircea_popescu: if you think trb is a hard nut to crack, picture reading, grasping postgres.
asciilifeform: but it is also not clear to me whether this can be done and the result still referred to as 'trb'.
asciilifeform: one theoretical solution to every type of blackhole other than the (theoretical) 'nsa sprays shit directly into the pipe on the backbone' is to make trb actually multiprocess
asciilifeform: i suppose for completeness one ought to include a '5' -- foolish folx who think that 4GB / non-ECC ddr4 / etc. is a trb node
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
asciilifeform: also i see some 'connect() failed after select(): Connection refused' which iirc is bleeding edge prb kicking trb out
asciilifeform: no diff on trb
asciilifeform: davout: it was exactly the same snore as in early trb
asciilifeform: and asciilifeform doesn't even sit in trb-foundation!
asciilifeform: i already get grumbles that trb is an asciilifeform-vertical.
asciilifeform: mircea_popescu: this destroys the ability to see that we in fact returned to genesis. has it occurred to you to wonder why even to have patches at all? why not everyone just signs the entire hindenburg titanic of trb every time he changes a line ?!
asciilifeform: (i.e. stuffing all of, e.g., trb, into one long document)
asciilifeform: it was a fairly unambitious generalization from things we had already been doing by hand in trbdom
asciilifeform: ( recall, we had been trb-ing with exclusively signed patches since start of trb, but folx other than asciilifeform were having headache determining the correct order to apply in )
asciilifeform: 'trb condom'
asciilifeform: looks almost as if it'd be a skin , front end running tcpwise in front of trb node
asciilifeform: at a certain point, if you attempt the operation, you start to ask 'why is there satoshi crapolade in my bitcoin2.0' rather than 'ooh neato, a repaired trb!'
asciilifeform: and then realized that the resulting patch WILL be 50,000 lines, and the output will look ~nothing like trb, and gave up.
asciilifeform: which is where a trb node is actually hanging for 10-50% of a given day.
asciilifeform: mircea_popescu, ben_vulpes, et al : the pill that would be needed to cure the locks retardation once and for all (and enable, e.g., queueing) while preserving semantics, would be to go through each and every function call in trb and determine if it A) Reads state B) Modifies state C) both D) neither
asciilifeform: at one time i ran a barbaric experiment where same box would run ~two separate~ instances of trb
asciilifeform: the one caveat is that this is probably not doable while preserving trb semantics.
asciilifeform: i'll add to this that in trb as we have it, you ONLY need blockchain to verify a potential mempool tx
asciilifeform: mod6: trb isn't multithreaded in the, e.g., apache, sense. it services clients round-robin style, and if it gets stuck at any point, this is what you get
asciilifeform: davout: chances are there is a crackpot pseudoimplementation of bitcoin in every language, cobol, malbolge, befunge, by this point. they are of 0 interest because not trb !
asciilifeform: it is in re the earlier gedankenexperiment. say trb operators stuck to the 'grandfather's pistol' principle entirely, and kept no record, other than current copy of blockchain, of the past. no checksums, etc.
asciilifeform: well presently trb nodes ~aren't~ operating strictly on 'race to the swiftest', they have the ancient checkpoint thing.
asciilifeform: current trb, by default, nails down the early (300k?) blox
asciilifeform: well not per current trb!
asciilifeform: ben_vulpes: i have nfi why you and mod6 did not pick it for a release, can only answer for myself. yes, the hardcoded header checksums thing is ridiculous. but no, there is such a thing as a historic, immutable planet earth blockchain, and trb ought to include default-on sanity check of ~some~ kind for long-ago blocks.
asciilifeform: ben_vulpes: all of the blocks in my chain validate per trb. (at one time i suspected that they would not -- but they do.)
asciilifeform: incidentally all of asciilifeform's public trb nodes descend from that one.
asciilifeform: it would still be interesting to have alarm bell in trb , connected to 'i booted and it looks like >$maxcoin bitcoin are circulating'
asciilifeform: it is necessary. afaik trb's miner has not been tested since... 2011?
asciilifeform: mircea_popescu: as i understand, you were referring to 'spin up trb node from 0 on real-life blockchain'. which more or less everyone involved has done, multiple times. his current thing appears to be the 'lan testnet' scenario i suggested a while back. where one pretends that the year is 2009.
asciilifeform: y'know, to see if trb miner actually works. and if indeed the thing can be put on alpha centauri.
asciilifeform: also imho ben_vulpes has a very spiffy project here and it deserves more brain cycles, he is actually testing the 'bitcoin on alpha centauri' scenario! i.e. replay of time, from genesis and up, in parallel universe, on trb.
asciilifeform: this part of trb is completely virginal 0.5.3 btw
asciilifeform: satoshi was not mining on trb eh
asciilifeform: iirc you need at least 1 on trb
asciilifeform: mircea_popescu: 'g' was result of my frustration with trb's plaintext tcp
asciilifeform: i'll point out that trb is ~190k tgz.
asciilifeform: to give some vague idea of complexity, 'eagle cad' is of about ~same binary mass as trb.
asciilifeform: incidentally : for so long as block verification remains O(N) and serial, trb is vulnerable to a very trivial malformed-block ddos
asciilifeform: my point is that artificially rationing connections to trb will lead to ~slower~ propagation, rather than faster -- unless it alleviates severa spamola, as my 'banhammer' did
asciilifeform: (the situation where trb nodes, in the ~collective~, can be persuaded to tune out the heathen world, is precisely it)
asciilifeform: sorta why i have not touched trb in quite a spell -- there is nothing left to do that is not 'a mutilation' imho
asciilifeform: it still very much itches in asciilifeform's brain that we still do not have any means for fixed peering in trb
asciilifeform: the bulk of the reason i even wrote the 'programmable verstring' patch to begin with is to determine, experimentally, whether enemy would willingly go along with displaying directory of public trb urinals, or not
asciilifeform: in related noose, there are at least 6 operating trb nodes, and that is just in the heathen catalogue! ( https://bitnodes.21.co/nodes/?q=/therealbitcoin.org:0.9.99.99/ ) and only those with default verstring
asciilifeform: trb is static and will run on literally any linux
asciilifeform: seems like if we want a graphical wwwtron -- will have to 'trb' one.
asciilifeform: mircea_popescu: problem is that the thing hangs on a megatonne of open Sores shitware that is >trb-sized
asciilifeform: tbh i do not have a clear picture of what use a trb-on-mac might be to anyone, given as the thing needs to be up 24/7 for any practical battlefield value
asciilifeform: trb is very often 2-7 behind
asciilifeform: jurov: i must admit that it has been eons since i set up a prb, and the last one i tested was iirc 0.8.something (which worked with trb)
asciilifeform: yalehasaquestion: trb ( therealbitcoin.org ) is the ~actual~ bitcoin client. approximately as-it-was in 2012, with minor cleanups.
asciilifeform: it may be the case that 'core 0.13.1' (which is an imposter pseudo-bitcoin client, see below) refuses to speak with trb.
asciilifeform: imho sanity in trb logs would include not only timestamp but such things as non-mutilated tx ids (wtf, srsly, are these 1st N bytes, or last, or wat) but also separation of blockchainchurch and mempoolstate
asciilifeform: iirc 'how to log' got caught up in the thread re whether trb wants to become own os or not
asciilifeform: ben_vulpes: iirc items such as oom are sent to stderr by trb
asciilifeform: ( and iirc trb still has no times in logz )
asciilifeform: using what patch ? standard trb dun have import..
asciilifeform: mircea_popescu: cheap vps will fall down just as readily when flooded (as will the trb node, mine or anybody's)
asciilifeform: trb, ssh, www, all.
asciilifeform: (and , for folks with poor reading comprehension, i will repeat - entire box is ~unreachable, trb node, ssh, 80, etc )
asciilifeform: the trb node just as dead.
asciilifeform: Framedragger: that 1 file is almost longer than ALL OF TRB
asciilifeform: earlier this year, i wanted to fit symmetric cipher into trb, and get rid of 'blackholing' etc. but mircea_popescu correctly pointed out that it is the Wrong Thing to cement a pseudoscientific abortion like AES (or ANY OTHER known symmetric cipher!) into place
asciilifeform: mempool really belongs chopped cleanly out of trb.
asciilifeform: incidentally, anybody else's trb node under 'askfor tx somecrapolade' ddos ?
asciilifeform: to have separate market, as in 'x prb == y trb coin', they gotta be circulatable separately