log☇︎
2100+ entries in 0.191s
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 !
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.'
asciilifeform: http://thebitcoin.foundation/trb-howto.html <<
mircea_popescu: so where's the trb+wires recipe ?
asciilifeform: this presupposes that you have a trb+wires built
Framedragger: probably worth thinking about it more, it'd be quite a spiffy thing indeed... that said, i have a more general concern with time-sunk-cost-to-trb. i do wonder how realistic it is to expect a trb-i in the years to come. if it is, then working on shitty legacy trb codebase is opportunity cost par excellence :( ; but, maybe testing harness could be generic enough to be easily re-usable.
a111: Logged on 2017-03-12 01:58 ben_vulpes: anyways, having thought about "testing" trb, i am interested to hear what kinds of tests framedragger would write
ben_vulpes: can even diddle trb-observed clock to get difficulty curve to do whatever
mircea_popescu: it means you feed a trb to be tested randomly generated "txn"
ben_vulpes: if afl is not a lurking piece of garbage, plugging trb into that might yield some interesting strange.
ben_vulpes: anyways, having thought about "testing" trb, i am interested to hear what kinds of tests framedragger would write ☟︎
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'
scriba: Logged on 2017-03-11: [21:18:59] <Framedragger> :). one decent part of devops is CI, i thought. it's even mentioned as possibility for trb dev http://btcbase.org/log/2016-05-15#1466922
a111: Logged on 2016-05-15 15:56 mod6: what i also want to build is a CI thingy for trb
Framedragger: :). one decent part of devops is CI, i thought. it's even mentioned as possibility for trb dev http://btcbase.org/log/2016-05-15#1466922 ☝︎
Framedragger: maybe not applicable to trb
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
Framedragger: mircea_popescu: sure, but do you expect to reach **10^24** nodes before trb-i?? (http://fd.mkj.lt/stuff/fsgraph2.png)
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
a111: Logged on 2017-03-10 17:16 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
mod6: On a brighter note, about to setup a new trb node this weekend outside of aws. So that's awesome.
a111: Logged on 2017-03-10 17:43 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 !
a111: Logged on 2017-03-10 17:16 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: 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: if you start seeing them ~regularly~ (say, trb makes it to 50 yrs from nao) you put in a l2 table.
Framedragger: yeah that's one reason i'm not too attracted to trb, tbh, the amount of sewage gruntwork required to decouple shit from the monolith.
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
Framedragger: at least i have the excuse of not having looked at the bdb problem / staying away from trb for the time being :p
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:
trinque: connecting trb to it now
Framedragger: yeah, okay; as long as it's not fixed-width trb-i, no way around this.
asciilifeform: if you gotta actually break compatibility with ext4 and write new kernelspace driver -- may as well design proper (b-tree) fs for trb.
phf: ben_vulpes: if a111 got moved to sbcl earlier, the redundancy conversation would not have happened, and people happily would be writing trb code instead
a111: Logged on 2017-03-09 01:17 asciilifeform: paradoxically a trb-i is light years easier than 'cleaned trb'
Framedragger: re. priorities and (natural) lack of 'global amazing konsensus priority list of shit to do', in my humble and very noob mind they are something like; 'p'; gossipd or partial iteration towards it; invoicing system; << these three'd useful for outside-tmsr interests fo sho; and nfi re. trb, as on the one hand it's supposed to be super important,
mircea_popescu: so trb-ing is a huge anti-impedancer for everyone who could be working on it.
mircea_popescu: if they manage to stumble in their own robes and throusers until 2030 or so, trb might even live!
asciilifeform: paradoxically a trb-i is light years easier than 'cleaned trb' ☟︎
a111: Logged on 2016-11-07 18:49 mircea_popescu: just as long as i pay 700 bux to the trb, it's not going anywhere.
mircea_popescu: aanyway, FG patch for trb wouldn't hurt.
asciilifeform: it is interesting how much, imho, moar readable these are, than trb.
shinohai: asciilifeform: http://btcinfo.sdf.org/trb/original-bitcoin/
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.
davout: it would have allowed some level of split, but anyway, this particular idea is dead since trb doesn't have this in-memory data structure
mircea_popescu: this'd be wallet-trb.
mircea_popescu: node-trb.
davout: i thought trb was keeping them in ram already
davout: in essence, that's already what trb does
mircea_popescu: trb too, for now, i guess.
davout: you mean trb?
davout: 2. the way the existing trb wallet currently works, mainly the automatic utxo selection
davout: http://fr.anco.is/2017/removing-the-wallet-from-trb-first-thoughts
davout: found out that i in fact hallucinated the existence of this index, which may or may not have been added later on to prb, but was absent from trb
davout: i thought i'd find an in-memory UTXO index, which i didn't. appears to me like trb will have to keep some sort of "watched addresses list" after all, or that such an index will have to be bolted in somehow
davout: so i did some reading re the wallet separation thing and ended up realizing i had an incorrect idea about trb's internals
trinque: also, speaking of wot.deedbot.org (and specifically the generated SVGs) and http://btcbase.org/log/2015-07-04#1186410 (which I have patches in hand to fix the build) I may have something of a usable trb map in the near future. ☝︎
shinohai: I still have a copy in archives, but haven't tinkered with it much. jhvh1 and trb keep me pretty busy.
Framedragger: Reuel: just fyi, and it's only my humble opinion, but you don't need the context of the whole trb to do the symlink experiment. from what i took of it, it's a matter of testing how various filesystems (probably starting off with ext4) can manage with (very) large numbers of nodes and large numbers of links to nodes. how seek times increase with those numbers of links to links, etc. (as an fs overhead, on top of hdd/sdd).
Reuel: however life is getting in the way at the moment, and I don't have time to go through all the TRB code, which is probably a must to understand the context of the experiment
asciilifeform: no one will ever confuse anything we might recognize as trb for any artifact from the distant Planet of Sane People.
a111: Logged on 2017-03-04 17:53 asciilifeform: there is no prioritization because of trb's fundamentally idiotic uniprocess socket handling. ( if there is no preemption - there can be no meaningful prioritization ! )
asciilifeform: because Being Able To Use Bitcoin might pay the bills, for node operator today (or may not, some folx are stuck operating a node for other reasons, say, trb dev work) but enemy can drive up the cost substantially , with no guarantee of an increase on the other side of the balance to match it
asciilifeform: and yes, this only works with nodes that have cryptographically hard identity. and not with the syphilitic orgy familiar to classical trb users.
asciilifeform: (in trb, you also, recall, have the tx index db, and literally nobody knows what the dynamics are there)
asciilifeform: in classical trb, you have the 1MB/10min worstcase. but tightbounds are better.
asciilifeform: (and with , i picture, much better detail than stock trb's log )
ben_vulpes: this is a desirable situation? that trb logging include timestamps and shit into log that which came from whom?
asciilifeform: there is no prioritization because of trb's fundamentally idiotic uniprocess socket handling. ( if there is no preemption - there can be no meaningful prioritization ! ) ☟︎
asciilifeform: and if you have a trb built with wires, it is 10min work (on client end), 10 seconds on the master.
asciilifeform: phf: most of today is re mircea_popescu showed a trb node that's been wedged, in a peculiar way, since july. but the l0g will still be there later.
asciilifeform: at this point i will recommend that -- when everyone has satisfied himself that 'wires' work -- every trb node oughta be wired to at least 1 known trb node
asciilifeform: though mircea_popescu's wedge is preventable, what trb really ought to do is start sending http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#1735 to all peers, starting with any 'wires' if present, whenever it goes for >1hr without a new block
asciilifeform: trb's response to an orphan is 'tell me mybestheight+1th block DAMNIT'
mircea_popescu: is this no longer happening in trb ?