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,
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.
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
mircea_popescu:
trb-shiva should be
trb-shiva ; if shiva-genesis also exists nothing is hurt thereby.
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: 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
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.
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.
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.
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" ?
a111: Logged on 2017-01-07 17:50 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" ?
☟︎ 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
mircea_popescu: if we make the
trb-i correct it should work like vtrons, multiple language implementations
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 mircea_popescu: this is what "
trb.n inherits network code" means. let it inherit.
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.
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.
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"
☝︎ mircea_popescu: still, the "frozen
trb because networking" or "because badlt done block check" etc can't go on forever.
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 ;
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 ☟︎