log☇︎
2400+ entries in 0.202s
davout: so with the eventual goal of cleanly amputating the wallet off of TRB I'm kind of wondering what the best approach is here,
asciilifeform: in turn it is also why i have an interest in a hypothetical nonbignumtronic (i.e. lamportronic) 'trb-i'.
asciilifeform: mircea_popescu: 3.x linux kernel; gcc 4.9; musltronic toolchain; emacs 24; trb; v; gpg 1.4+rngpatch+timingleakpatch .
asciilifeform: this is sorta why i wanted to put out trb, frozen gcc, linux, etc. on a ~pressed aluminum~ cd
mircea_popescu: asciilifeform ben_vulpes and davout are evidently struggling with the trb ; so was mod6 before we fucked up his week with v stuff ; diana_coman is purging idiocy out of eulora and so on. plenty of people.
asciilifeform: and trb-genesis let it be CLEARLY and PERMANENTLY marked as not-child-of-mine, for each of the signatories.
asciilifeform: but Framedragger has a larger and imho relevant point, the ecc in trb is part of the world-as-we-found-it
asciilifeform: trinque: a good chunk of the appeal, i dare say, of trb, is the ~pedigree~
asciilifeform: iirc mircea_popescu still does not use trb to touch actual megacoinz
asciilifeform: is trb in use 'in production' somewhere ?
asciilifeform: trinque: consider the trb-genesis as a successful use case of the thing i am asking for.
trinque: asciilifeform: seems the problem there has as much to do with the fact that a gentleman would have to dedicate a very large part of his life to making further, sweeping improvements to the trb codebase
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.
mod6: <+mircea_popescu> either it builds in its own independent tree, or else it declares an antecedent in the trb tree. << so in the latter part here, should my 'foobar.vpatch' that just adds one file without any antecedents or descendants actually inherit an antecedent, in this case 'genesis.vpatch' ? just trying to understand ...
mircea_popescu: either it builds in its own independent tree, or else it declares an antecedent in the trb tree.
mod6: Say that we have a flow, like trb, with all sorts of vpatches that stem from one single root. where that root is designated as a 'root' because all of its inputs are 'false'. what should happen with a vpatch that, for instance, just adds a file to the source and has no antecedents, nor decendants.
thestringpuller: !#s blackhole trb
thestringpuller: is there any live TRB node that isn't blackholed right nao?!?
mod6: i'm making some good progress on my V changes this week. hopefully won't be too long be for I can help you out with any wallet related things you might be doing on trb.
davout: pretty good! my trb node is synced around october 2015
asciilifeform: makes trb look good.
thestringpuller: asciilifeform: is NSA-TRB down? started up an old node to sync... and get: http://wotpaste.cascadianhacker.com/pastes/6m3GH/?raw=true
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')
Framedragger: (nice trb dev log there btw)
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.
mod6: So basically, the deal is, that when using TRB, I have one user in my wot, say "mod6", and I drop out a vpatch from the flow, say "asciilifeform_dnsseed_snipsnip.vpatch" by moving it's seal to "asciilifeform_dnsseed_snipsnip.vpatch.mod6.sig.foobar", then I expected a few things to happen.
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. ☝︎☟︎
ben_vulpes: whaack: is this a trb node?
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.
davout: http://btcbase.org/log/2017-01-09#1599658 <<< so basically any fucktard who can mine a block can DoS TRB into oblivion ☝︎
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.
ben_vulpes: a question i have been wondering about for long is "why does the trb tree sit in a 'bitcoin' directory, wherever it's pressed", but it is not particularly irrelevant.
ben_vulpes: trinque may confirm: i believe that this is due to asciilifeform grinding (trb-)genesis.vpatch from an a/ and b/ containing a directory 'bitcoin'
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.
adlai: no, and my trb node never finished syncing either
a111: Logged on 2017-01-07 20:48 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
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 ☟︎
a111: Logged on 2017-01-07 17:49 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" ?
gabriel_laddel_p: http://btcbase.org/log/2017-01-07#1598267 < Thanks for reminding me. I don't trb, so went looking for them last time I was working on the LiveUSB, failed to find them and then continued working using the strategy I was prior. ☝︎
a111: Logged on 2017-01-07 17:50 asciilifeform: mircea_popescu: the 'lisp trb' is sussman's 'scheme83' chip.
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
davout: asciilifeform: none in particular while discussing trb, "trb uses openssl, which is vulnerable to side channel attacks" came up
davout: from where i stand it seems to me that trb would be vulnerable to it when signing transactions
asciilifeform: i did say 'trb worx great with trad diff' neh
a111: 4 results for "\"trb-i\"", http://btcbase.org/log-search?q=%22trb-i%22
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
BingoBoingo: And they work off of some poor folk voucher system instead of actual trb
davout: have trb rescan the UTXO for each "gimme-UTXOs-pertaining-to-these-addresses" and see how that goes
davout: for the cost of a 20gb index the wallet code can be completely removed, and implemented as a couple light scripts on top of TRB
davout: http://btcbase.org/log/2017-01-04#1596028 <<< not in trb as far as i can tell, i can tell the thing to 'generate' etc. ☝︎
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?
a111: Logged on 2017-01-03 20:48 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.
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')
a111: Logged on 2017-01-03 21:29 asciilifeform: though what i pictured is that trb can finally produce the motherfucking ~book~ and it will be possible to start rewrite...
davout: http://btcbase.org/log/2017-01-03#1595836 <<< my image is more like: "trb is this thing from which more and more is removed, until only the radioactive code consisting in ball of tightly packed hot wires which we proceed to put in a little box in which epoxy is poured, and is only interacted with as some black box" ☝︎
deedbot: http://fr.anco.is/2017/removing-the-wallet-from-trb-first-thoughts << fr.anco.is - Removing the wallet from TRB, first thoughts
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...
a111: Logged on 2016-12-20 19:40 mircea_popescu: at the very least block digestion and peering must be cleaved in trb
trinque goes to find the "cleave the network fiddling and block verifying parts of trb" thread
trinque: davout: hard to say with current rats nest if things could be that cleanly separated ~starting from trb~
davout: still working on my take on cutting the wallet out of TRB ☟︎
asciilifeform: and i was quite surprised when starting trb and noticing that it was absent there.