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
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.)
asciilifeform: trinque: consider the trb-genesis as a successful use case of the thing i am asking for.
mircea_popescu: it can even be a collective key, perhaps not in the sense of actually sharing the privkey, but perhaps trbf/holder signs items at request ; with the understanding it's all foundling crap anyway
mircea_popescu: mod6 i expect the correct solution going forward is : a) for someone (maybe trbf ?) to make a Wildman McFucksticks key which b) will be used to sign a compliant rebase of tinyscheme / anything else anyone finds in the woods and wants to sign.
asciilifeform: why does trb-genesis get special treatment in mircea_popescu's scheme ?
asciilifeform: note that we did ~same thing for trb genesis.
mircea_popescu: trb-shiva should be trb-shiva ; if shiva-genesis also exists nothing is hurt thereby.
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
mircea_popescu: all patches to trb tree must refer to an antecedent in the trb tree. no exceptions. if "nothing comes to mind", genesis is a fine default.
mircea_popescu: either it builds in its own independent tree, or else it declares an antecedent in the trb tree.
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
mircea_popescu: you understand nothing they leveraged works ? they ain't got a browser. google is trying to rescue 20 years of weveling with dubious results. there's no python 3. there's no ipv6. there's no trb. there's no eth. there's nothing. NOTHING.
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.
mircea_popescu: anyway, that aside, fixing this in trb may be worth the doing. though in my mind it was slated for when we actually do trb-i, to be shot in head with the whole "script" idiocy.
mircea_popescu: tbh /me has little intention to support anything but the above in trb-i. no fucking "scripts". name your input, name your output, sign. that's it.
asciilifeform off to trb room to verify this statement. and then to bed.
asciilifeform: per trb.
mircea_popescu: phf ben_vulpes : it won't corrupt anything if the berkley db is ran in "detached" mode, which it prolly should be. i don't recall if we put this in the trb or not.
mircea_popescu: so that it's trb_mod6_doesgirlsonboats.vpatch vs vtron_phf_addsnamespaces.vpatch. no conflict possible.
mircea_popescu: anyway, entertaining the thing as you describe at face value : if indeed your concern is a sort of bastardization as conceptually constructible from the foregoing, then the correct move is to build your masamune on musl and attach a license that forbids the empire (such as for instance the trb license ; or else one stating to use must be in l2, or rated by you, or any such thing). this will mostly protect you both technically
asciilifeform: mircea_popescu: the 'lisp trb' is sussman's 'scheme83' chip.
mircea_popescu: anyway, i'm not entirely up to speed re sad state of lisp world. i expect it's in the shitter, but not exactly clear how. is there any merit to the nude assertion that "lisp is a shittier thing than trb, because trb at least has SOMETHING that can be made into a musl ; whereas lisp does not" ?
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
mircea_popescu: !#s "trb-i"
mircea_popescu: if we make the trb-i correct it should work like vtrons, multiple language implementations
asciilifeform: trb will probably remain in trad style 4evar
mircea_popescu: but for eg trb work, +++ style is quite at home. it is c after all
mircea_popescu: this is what "trb.n inherits network code" means. let it inherit.
asciilifeform: stock trb mempool
mircea_popescu: i don't think today's logic does anything ; and i don't expect carrying it forward is useful. spec does include room for trb.n to do some banning, including on the basis of passively exfiltrated data from trb.b. that a protocol for this purpose may later develop i don't dispute, but it's not included both because it's not needed and because it can't become a "dependency". it's not.
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..?)
mircea_popescu: trb.b
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...
mircea_popescu: still, the "frozen trb because networking" or "because badlt done block check" etc can't go on forever.
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
mircea_popescu: anyway, the great gain is that no two elements need/have write access to the same thing by this scheme. in point of fact one way to look at current trb/prb is to say that they have "write locks" on all the fucking time and deadlock.
mircea_popescu: in particular N.B should be "older overwrites newer" style ring buffer. of particular concern are situations where the buffer is set shorter than the longest reorg, in which case the node will wedge. TRB.N not accepting blocks with index lower than highest of B.B is for sure not feasible. "how many behind" should be an operator knob.
mircea_popescu: in any case : TRB.N needs write access to N.B and M.T and read access to B.B ; TRB.B needs read access to N.B and write access to B.B and B.T. it may be a good idea to also give TRB.N read access to B.T but this should be operator-knob
mircea_popescu: otherwise it is discarded. B.T may be pruned (according to arbitrary address list, for instance). Rate limiting in TRB.N may be constructed to observe N.B items that fail to propagate to B.B and ban the originating peers.
mircea_popescu: TRB to be split into two parts : TRB.B and TRB.N. Queues B.B B.T N.B to be created. TRB.N inherits the code to connect to peers. TRB.N reads blocks from peers, and puts them in N.B. TRB.N reads txn from peers and puts them in M.T. TRB.N does nothing else (with the possible exception of rate limiting for peers). TRB.B reads N.B and verifies the blocks. if the block is verified it is added to B.B and its component txn to B.T ;
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.
mircea_popescu: http://btcbase.org/log/2017-01-01#1595094 << wallet needs to be fixed, which yes reduces to not much reuse of the current item, but you can't have trb without a means to pay. the miner is iffier business, and really i can't conceive why it'd be a priority. let it be, do useful things besides.
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.
mircea_popescu: davout trb does not implement any of the prbisms. this means that ANY innovation included by the power rangers is a "while it lasts" thing, and building on top of it is setting one up for tears.
mircea_popescu: no, actually, trb should apply the above scheme EXACTLY like how v applies patches : you populate a wot with acceptable addresses
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
mircea_popescu: this'd make some fine subject of a priority work order, the only problem is that it's so intricate and we aren't fans of doing the work n times. but once trb sits down on a sql-fs it would all fall in place.
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
mircea_popescu: you know, exactly how trb work proceeds also.
mircea_popescu: the legacy bdb is still in trb TO THIS DAY
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)
mircea_popescu: ben_vulpes which of the trb genesis seals are seal and which reseal ?
asciilifeform: it was a fairly unambitious generalization from things we had already been doing by hand in trbdom
mircea_popescu: i perceive no benefit to, eg, getting everyone to use mod6's or alf's or anyone else's v implementation, as opposed to the present situation ; just as i perceive no advantage to getting everyone to make "his own" trb.
mircea_popescu: http://btcbase.org/log/2016-12-22#1587923 << i am fwiw satisfied that it's qutie mroe than this : vs aren't on btcbase because they don't fundamentally belong on btcbase, because unlike public trb "we all use this" they're private "my girl will dance the way ~i~ want her to dance and stfu". there's a much more limited set of rules re what vtrons should do ; than re what trbs should do.
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 )
mircea_popescu: asciilifeform to be precise : i can't turn the greek string into an english string for you for the same reason you can't turn trb into lisp code for me. "but alf, it compiles! a lisp version must exist!" hurr. i don't propose "because you can't take object code and make me lisp source it follows no c sources existed" do i ?
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
mircea_popescu: at the very least block digestion and peering must be cleaved in trb
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.
mircea_popescu: pretty sure various people (myself included) did full trb blockchain download ; but mimi's very open and usefully so.
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
mircea_popescu: !#s trb
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.
mircea_popescu: also in which vein, see the discussion re busybox and the complete trb machine tmsr created for deployment on pogos (and the whole discussion with pogos) ; also perhaps of interest the failure to create a useful gentoo and so forth.
mircea_popescu: or alternatively read the various discussions in the log and mailing list re trb reform.
mircea_popescu: well, pick up the V tree and submit a patch ; ben_vulpes is already running http://cascadianhacker.com/update-mimisbrunnr-last-block-received on the trb infrastructure.
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 ?
mircea_popescu: anyway. if we were to bother with this we'd best fix all the other problems too, so the current miners wouldn't be able to mine trb anyway.
mircea_popescu: just as long as i pay 700 bux to the trb, it's not going anywhere.
mircea_popescu: this is connected. simmer down and stop confusing yourself. you said : <asciilifeform> going briefly upstack, my understanding is that this particular batch of forkolade is effectively 'hard', in that no trb-generated tx is likely to be mined. and i said <mircea_popescu> if it is, whatever, we'll release a proper trb and they can all go hang. im pegging it.
asciilifeform: to have separate market, as in 'x prb == y trb coin', they gotta be circulatable separately
mircea_popescu: asciilifeform to peg as in a currency, 1 trb = 1 prb to start. may devalue as time goes by of course.
mircea_popescu: if it is, whatever, we'll release a proper trb and they can all go hang. im pegging it.
asciilifeform: going briefly upstack, my understanding is that this particular batch of forkolade is effectively 'hard', in that no trb-generated tx is likely to be mined.
asciilifeform: ( the other prong of the front is the attempt to make trb difficult to use reliably by preventing effective quarantine of derp nodes and their tx)
mircea_popescu: anyway. it significantly weakens trb, which they're more than welcome to.
asciilifeform: (summary: usg's most recent attempt to pound in the cock 'halfway', 'segwit', consists of prb churning out txen that result in 'anyone can spend' from trb pov, but miners are to 'agree never to process counter-softforkian tx', a la 'timelock' etc)
mircea_popescu: would you want someone working on trb on the basis of having read the book or on the basis of having watched "the videos" ?
asciilifeform: trb absolutely gives no fuck if it cannot find the network.
asciilifeform: incidentally you can make this out of CURRENT trb simply by putting it on a box without a nic
asciilifeform: thestringpuller: how do you propose to 'check against multiple trb nodes' on an airgapped signing box ?
mircea_popescu: anyway. to not get entirely sidetracked : the exact sense in which wallet should be separated from rest of trb needs a lot more thinking.
asciilifeform: and pretty much everyone who has attempted to fire a tx using trb prior to mod6's 'S' patch, now has a supply of such 'evil' coin with which to test this hypothesis, if he wants.
asciilifeform: trb wallet is every bit as broken as prb wallet in this respect
asciilifeform: and the glomming of otherwise separate concerns is one of the things that makes reading trb a reliable headache.
mircea_popescu: sadly. the main thing that holds back sanevelopment on trb is the fact that whatever you want to discuss everyone starts muttering curses and mashing kbd about the 10bn other things connected.
mircea_popescu: definitely trb fork will have a sane tx-to-block coding scheme
asciilifeform: might be lulzy to cross-check with phuctor, ben_vulpes's trb nodes' banhammer lists, etc.
asciilifeform: https://stashnode.com << in other lulz, 'why build a trb node, buy a prb box from stranger today!'
asciilifeform: and, eh, 'v', or trb, or various other items contemplated here, fall much closer to the jet than to the tv set.
mircea_popescu: besides, at some point we'll get rid of sha2 in trb, and then we'll know.
asciilifeform: mats: you oughta port trb to it!111
asciilifeform: http://btcbase.org/log/2016-10-09#1554091 << you would have to begin by putting shiva back in... it isn't in the mainline trb (on account of questionable usefulness)
asciilifeform: possibly answer is, trb thinks i sent it to neverneverland ?
asciilifeform: the thing i do not understand is, how does the thing not fork? say i fire up a prbtron and prbsend to A. then fire up trbtron and send same coin to B.
mircea_popescu: currently some miners process, eg, 3-leading bitcoin addresses. while that lasts, trb can send money to you. once it goes away - can send no longer, resulting in some lost bitcoin (practically, sent to unspendable address)
mircea_popescu: asciilifeform your trb node is not capable to send money from derpy addresses ; which is ok because it's also not able to send to them. other people are more than free to do whatever the fuck they like.
asciilifeform: does it thereby follow that prb and trb have differing notions of how much coin is contained in A ?
asciilifeform: you could use trb-rotor almost as-is, if you went to this.
mircea_popescu: if anyone is inclined to maintain forks of any linux distro (much in the manner of trb - to clean, not to "support"/utf/systemd/etc) we can prolly work something out.
asciilifeform: otherwise one day you discover 'surprise', gcc6 or whatever won't build trb, or worse, builds-with-boojum
asciilifeform: for so long as you are still using traditional trb, you are stuck with some variant of this.
asciilifeform: and, incidentally, recall that we reground the trb genesis once.
asciilifeform: it made marginally more sense re the trb patch, but even there mircea_popescu insisted on the regrind.
asciilifeform: ( i could even see an argument that, e.g., rawtx eater doesn't belong in trb , and that tx ought to be injected via the ordinary tcp method. but i dun recall having this argument )
mircea_popescu: there's no specific problem known at that height ; trb does tend to want to use about 4gb or so if it can get to it.
asciilifeform: there is fragging. which is why current trb runs indefinitely in a footprint of ~4GB.
asciilifeform: shinohai: trb memory pighoggery prevents the practical trbification of any of these. but it is ~impossible to fix without rewriting good chunk of it.
asciilifeform: shinohai: don't expect to do much trb on the g1 board that comes with the sage - it has soldered-down 1GB of ram
asciilifeform: the unparallelized-yet-wholly-parallelizable block verification is the biggest embarrassment in trb
asciilifeform: of trb?
mircea_popescu: actually since you brought it up it reminded me of vague discussion, so let's make it explicit. mod6 asciilifeform i dunno how practical it is yet, but eventually trb block mechanics will have to be expanded to memory datastore, so that it holds the current blk000n it's working on in ram and dumps it to disk only when full. MUCH easier to cache a disk with no writes on it.
mircea_popescu: well massive overkill. trb wants what, 4g ? i was thinking more in terms of tb.
mircea_popescu: asciilifeform it does link ? http://thebitcoin.foundation/trb-howto.html
asciilifeform: !~later tell mircea_popescu your new page's section IV oughta link to trb
asciilifeform: (and trb does in fact store orphaned blocks eternally)
asciilifeform: esp. if coupled with actual working wireshark + trb node.
mircea_popescu: same thing as trb, but with lisplisp instead of cc
asciilifeform: ben_vulpes: if you read the code, you will notice that trb is, at most times of 'very very busy bee', quite unready to react to rpc command because one of the global locks is engaged.
asciilifeform: the trb method.
asciilifeform: which is why any item that is of interest here, ought to be picked up and nailed to the floor, as i nailed trb's deps.
asciilifeform: a specification can exist as a real object (which is very painful, consider the standard kilogram block, or trb) or an ideal object.
asciilifeform: and i have reason to suspect that mpb is catastrophically defective and fails to pass tx to trb (which, recall, is a reference, one does not get to say that it is broken in vs the unpublished mpb) under certain circumstances.
asciilifeform: half the time i do not even know if he is speaking of a trb -- or mpb! node.
asciilifeform: incidentally, i still have nfi what mircea_popescu's patchset is. understandably he can stay mum about it if he likes, but it makes his debugging reports ~useless from a trb pov.
asciilifeform: (trb is 100% static, i hope this is not news to anyone)
mircea_popescu: http://log.mkj.lt/trilema/20160913/#28 < no trb node of mine ever allocated 4gb ram. there's something weird there.
asciilifeform: mircea_popescu: if either of my trbtrons aren't answering, now or whenever, gimme a ping
mircea_popescu: incidentally, what's the current list of public trb nodes ? i have -connect=108.31.170.49 54.187.227.228 46.166.165.30 91.218.246.31 172.86.178.46 50.168.67.12 of which a coupla be answering.
mircea_popescu: this said, i see absolutely no problem whatsoever implementing trb nodes on sign-hello.
asciilifeform: i even built trb for it.
asciilifeform: conventional in the 'trb as we now have it' sense.
asciilifeform: at one time i considered adding, e.g., rate limiter, to trb, but decided that it is not the Right Thing.
asciilifeform: in other noose, 70.33.211.11 (yes, 1 box) has been ddosing trb nodes, in particular zoolag.
asciilifeform: we burned it out of trb with hot irons, first thing, for a reason.
asciilifeform: thestringpuller: not satisfied with the cookbooks on trb mailinglist ?
asciilifeform: they aren't flocking to trb, or mpex, etc.