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
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.
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)
ben_vulpes: wasn't in the mood for trbquest on civvy machine
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
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.
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.
a111: Logged on 2017-01-01 10:33 davout: ben_vulpes: can you point me to the thread where "keep the miner in trb" was discussed?
davout: ben_vulpes: can you point me to the thread where "keep the miner in trb" was discussed?
davout: in other news imma sink some time in documenting the merciless wallet code excision that I think is the right(tm) approach for TRB
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.
davout: asciilifeform: so you're saying a block including a transaction with locktime > block height is considered valid by trb ?
mircea_popescu: no, actually, trb should apply the above scheme EXACTLY like how v applies patches : you populate a wot with acceptable addresses
davout: trb should be able to shit list of unspent outputs, optionally filtered by address
davout: anyway, i guess my position basically boils down to: "as far as trb proper is concerned, best wallet is no wallet. but sane indexing mechanisms"
a111: Logged on 2016-12-30 19:46 davout: trb being able to list utxos given a bunch of addresses would be pretty obviously needed
ben_vulpes: any sane trb that doesn't index tx on output address i suppose
asciilifeform: and in any sane future trb.
asciilifeform: even in the oldest trb.
davout: trb being able to list utxos given a bunch of addresses would be pretty obviously needed
asciilifeform: my contention is that a trb with entirely removed unspent-selector is not usable-naked.
davout: i didn't say it had to come *with* trb
davout: script it on top of trb, don't integrate it directly in there is what I think is the correct solution
davout: i content that these should be the ~only~ knobs at trb level
davout: yeah, ben_vulpes told me in your very chan, if i can help it i'd be happy to, it does sound like a pretty good starting point for me to hack on trb
davout: hence my previous questions about the state of this particular functionality in trb
davout: i'm still curious what would make this kind of setup where i script "prb dumpblock | hex2bin | trb eatblock" much faster than syncing from network if the bottleneck is indeed the block verification?
ben_vulpes: http://btcbase.org/log/2016-12-30#1593697 << scripting is too much work, just manually dump every block and then manually load it into trb once the previous eat completes. nice meditative activity
davout: but then, how can it vastly improve sync time to feed blocks from same machine instead of letting trb suck them from the network?
davout: what's the syncing bottleneck on trb's side?
davout: ah yeah, i'm currently syncing off ben_vulpes, i was wondering if dumping blocks from prb and then eating them with trb would work
davout: http://btcbase.org/log/2016-12-30#1593472 <<< trb -> trb only possibru, or could prb -> trb also work?
asciilifeform: mircea_popescu: if you think trb is a hard nut to crack, picture reading, grasping postgres.
a111: Logged on 2016-12-30 09:13 davout: out of curiosity, how long did it take trb node operators to fully sync?
davout: out of curiosity, how long did it take trb node operators to fully sync?
a111: Logged on 2016-12-29 23:08 asciilifeform: also i see some 'connect() failed after select(): Connection refused' which iirc is bleeding edge prb kicking trb out
ben_vulpes: otherwise trb may decide to ask utter randos for blocks
davout 's trb node is now up and apparently syncing at 62.210.206.141
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.
ben_vulpes: asciilifeform: any idea how prb identifies a trb node?
asciilifeform: also i see some 'connect() failed after select(): Connection refused' which iirc is bleeding edge prb kicking trb out
pete_dushenski: mircea_popescu: i don't disagree from a philosophical standpoint but nor can i tolerate having dead fucking trb nodes. that i should have to reboot a machine ~daily~ is the death of bitcoin. yukoners never had it so bad.
asciilifeform: no diff on trb
pete_dushenski: now-frozen machine has lots of cores, lots of ram, and is running trb.
asciilifeform: davout: it was exactly the same snore as in early trb
pete_dushenski: speaking of tagging, looksee what i spotted at the base of a lamp pole recently : http://www.contravex.com/wp-content/uploads/2016/12/TRB-everywhere.jpg
mircea_popescu: you know, exactly how trb work proceeds also.
mircea_popescu: the legacy bdb is still in trb TO THIS DAY
phf: it follows the existing naming convention of thing-genesis with "genesis" reserved for 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)
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
jurov: to introduce it into trb would, in my understanding, would make folks apoplectic
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 )
mod6: and in the context of trb, I would end up with, currently, just genesis.vpatch pressed out in 'output_press_dir'
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
a111: Logged on 2016-12-20 20:10 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: 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
ben_vulpes: all of a sudden i want to collect data on how long trb takes to return from a simple getinfo call, per your above protocol
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
tb0t: Project: trb, ID: 35, Type: I, Subject: Investigate blackhole, Antecedents: , Notes: Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635
mod6: !%p trb 35
mod6: !%a trb I "Investigate blackhole" "Investigate what might be occuring with the so-called black-hole, described here: btcbase.org/log/2016-12-20#1586635"
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
ben_vulpes: might be interesting to patch trb to dump relevant connection's self-identification string
ben_vulpes: but i mean blackholing as artifact of some other poorly written client, instead of script opening sockets to trb nodes
ben_vulpes: sure, trb shoulda been aborted
tb0t: Project: trb, ID: 33, Type: F, Subject: Possible DB Replacement with UNIX Filesystem, Antecedents: , Notes: http://btcbase.org/log/2016-11-01#1561093
mod6: !%p trb 33
tb0t: Project: trb, ID: 34, Type: F, Subject: Configure Checkpoints by Configuration File, Antecedents: , Notes: Allow for a user to set a given checkpoint within a configuration file. See discussion: btcbase.org/log/2016-12-20#1586436
mod6: !%p trb 34
mod6: !%a trb F "Configure Checkpoints by Configuration File" "Allow for a user to set a given checkpoint within a configuration file. See discussion: btcbase.org/log/2016-12-20#1586436"
mod6: <+davout> did we just add tmsr-db on the todo? << there is a ticket for this: http://thebitcoin.foundation/tickets/trb_tickets.html#6
ben_vulpes: entirely unrelatedly to anything else, does trb's `getmemorypool' actually work?
trinque: speaking of killing yourself, the db design for trb deserves *long* thought
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.
ben_vulpes: embarassing as it is that i'm only now finding that trb doesn't solipsistically mine, i did determine that it validates the whole chain.
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'
mod6: and if it is required to be attached to at least one other node, then that may be a problem. We could still test on a lan, but you'd have to have two trb nodes on that lan to get past that line of code.
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.
mod6: phf: oh i get it. i lead by example with trb on this. there is no good solution here. we do not want blobs in V, and somewhere between a-z you end up with a blob that must get signed along with the vpatches.
mod6: <+asciilifeform> ---- except that i can't because apparently we have 0 working infrastructure for actually releasing v code << i disagree with this. what we have, and trb isn't the only one who's done this, is; you make a mirror, and then v.pl deals with this. you grab all the vpatches you want, and the sigs from people you trust, and you place them in v, then you do what you wanna do.
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
deedbot: shinohai rated ben_vulpes 3 at 2016/12/11 03:11:16 << http://cascadianhacker.com/ #trilema trb lisp
phf: only for the lack of trying, but even now elsewhere i'd be a regular trb guru :p
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.
adlai: !~later tell mod6 may I please be granted admission to your trb dev channel(s)?
adlai: ;;later tell mod6 may I please be granted admission to your trb dev channel(s)?
shinohai: returned 22:08 deedbot shinohai updated rating of trinque from 3 to 3 << deedbot, lisp, trb
deedbot: BingoBoingo rated shinohai 3 << Regular Qntra Contributor and TRB-ist
mod6: While doing such work, I decided it'd also be nice (if not for trb integration, for myself) to have some tools to help me construct a rawtx.
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.
a111: Logged on 2016-12-05 14:24 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: 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.
a111: Logged on 2016-12-03 21:36 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.
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.
shinohai never really has problem when using trb .... tx fee is set at 0.001
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
phf: http://btcbase.org/log/2016-12-01#1575340 << buildroot exclusively generates linux binaries, so any bsd build has to be done manually. but fwiw my openbsd patch still works and still produces a working trb
asciilifeform: trb is very often 2-7 behind
adlai recently tried pressing & building trb on fbsd; did not go well, needs another attempt. but for now - sleep.
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)
jurov: asciilifeform: iirc anything past 0.10.x won't speak 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.
shinohai: Best way to learn is to go to http://thebitcoin.foundation/trb-howto.html and stand up your own trb node.
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
a111: Logged on 2016-11-28 17:08 asciilifeform: ( and iirc trb still has no times in logz )
asciilifeform: ( and iirc trb still has no times in logz )