tmsr - Search: "trb-i"

BingoBoingo: After a long stretch of not needing to give a day or two and seeing the whole trb-iverse visible from my chair stuck on the same block, I figure why not try to forcefeed the problem block

mircea_popescu: phf we've all ranted about it at some time or another. needless to say replacement rsatron does not include idiotic half-baked state machines. much like trb-i doesn't include "accounts" nonsense.

a111: Logged on 2018-10-01 14:22 asciilifeform: i could even see an argument that the charter could permit 'trb-i' work under the flag of tbf. but that's as far as it goes, per my reading

asciilifeform: i could even see an argument that the charter could permit 'trb-i' work under the flag of tbf. but that's as far as it goes, per my reading ☟︎

asciilifeform: while imho this is not a 'let's do this right nao' scheme, it is prolly the Right Thing in re 'trb-i' block propagation. no moar 'block withholding' nonsense. no reason why trbi should not own ionosphere the same way mircea_popescu projected bitcoin will 'own' mains current generation capacity.

lobbes ended up getting a cheap dedi out in kansas or w/e for 25 bezzlebux. Soley for trb-ing. Drawback is it has hdd, but going to try and use the aggressive pushgetblocks patch. Seems like diana_coman had nice results with similar experimentation

a111: Logged on 2018-04-17 01:12 lobbes: I'm probably too poor, but if it is in my range I'll most likely try and grab one for trb-ing

lobbes: I'm probably too poor, but if it is in my range I'll most likely try and grab one for trb-ing ☟︎

asciilifeform finds the 'tx references outputs of old tx, rather than addrs' to be a profoundly trisomistic shitoshiism -- but we can come back to this at next 'trb-i' thread

a111: Logged on 2017-02-28 05:40 asciilifeform: [BTC-dev] (CRACKPOTTERY) Notes re: one possible "TRB-I".

lobbes: in other questions: Prompted by up-stack threads and after much log reading I've concluded that a SSD is a must for trb-ing. Would an external usb SSD be adequate, versus, say a SATA connection?

mircea_popescu: in the sense that rather make that, best make new comp. trb-i all over again.

mircea_popescu: well, hopefully this problem gets resolved by crap not making it into trb-i

a111: Logged on 2017-03-20 00:42 mod6: So I'll be getting into the thick of that very soon. Lot to do to get trb-i going.

mod6: So I'll be getting into the thick of that very soon. Lot to do to get trb-i going. ☟︎

mod6: I do want to outline more of the trb-i work in tickets, and do some clean-up/management of existing trb tickets.

a111: Logged on 2017-02-27 16:56 mircea_popescu: but the correct trb-i might just as well end up this situation where block reward is 1mn bitcoin, and it dies within 1mn blocks. so all mining does is produce ~ a lease ~ on a chunk of bitcoin. and the value of old bitcoin is monotonically decreasing over their lifetime.

asciilifeform: sooo per my reckoning, you can have sane-trb-indexer, but now every tx gotta have a field for 'was replaced?' -- and if bit is set, indexer goes and looks at the collision table, the previous lookup now 'didn't count'

mircea_popescu: this is at the core of the argument in favour of a trb-i implementation.

Framedragger: ..which means that the latter should be dropped eventually, i guess (but then cue my question 'why not just work on trb-i if no compatibility with heathen prb network')

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.

Framedragger: mircea_popescu: sure, but do you expect to reach **10^24** nodes before trb-i?? (http://fd.mkj.lt/stuff/fsgraph2.png)

mircea_popescu: and this is a very important point, and cogent throughout, including re trb-i design

Framedragger: yeah, okay; as long as it's not fixed-width trb-i, no way around this.

a111: Logged on 2017-03-09 01:17 asciilifeform: paradoxically a trb-i is light years easier than 'cleaned trb'

mircea_popescu: so trb-ing is a huge anti-impedancer for everyone who could be working on it.

asciilifeform: paradoxically a trb-i is light years easier than 'cleaned trb' ☟︎

mircea_popescu: yeah. and since you mention it, trb-i definitely needs a clarified push-or-pull model because the current system is the soul of unconsidered adhocery

PeterL: while we are talking about things to stick in TRB-I, how about lowering the block size by an order of magnitude or so?

mircea_popescu: this item definitely counts for your grand list of trb-isms. on the strength of that, "computable", i ask no more.

mod6: yeah, trying to keep up with all these posts. just started this one on "possible trb-i"

BingoBoingo: asciilifeform: In my mind trb-i is discussion piece. Ideal may be impossible. trb-i may end up being way to consider idea for trb-b which suceeds trb-a (a is for arse)

asciilifeform: BingoBoingo: keep in mind, it's ~a possible~ trb-i, not ~the~... thing's quite certainly still in 'matrix mechanics' stage of life, and who knows, for how long.

BingoBoingo: Oh the Trump flensing knife lulz come out tonight, while still digesting trb-i theory. What a time to be live!

asciilifeform: the fixed-width-tx is a provable component of any long-term-sane trb-i. regardless of what other parts are included or excluded. without it, you get rapid rot.

asciilifeform: asciilifeform's aim was to consider gedankexperiment trb-i where this cock is turned around radially, at the miner. who, reaping most of the cake, ought to also absorb the cock.

asciilifeform thinks 'holy fuck is the trb-i article looooong;' who will have the strength, to read this.

asciilifeform: trinque: say we stick to the trb-i thread. gotta specify what specifically about your concept of trbi, that would remove the incentive for miner secrecy that exists in classical bitcoin.

mircea_popescu: but the correct trb-i might just as well end up this situation where block reward is 1mn bitcoin, and it dies within 1mn blocks. so all mining does is produce ~ a lease ~ on a chunk of bitcoin. and the value of old bitcoin is monotonically decreasing over their lifetime. ☟︎☟︎

asciilifeform: to revisit much further upstack, to http://btcbase.org/log/2015-02-14#1018732 ( via mircea_popescu's latest article ) -- consider a 'trb-i' where a tx carries proof of work, and is likewise mined as is the block ☝︎

asciilifeform: while we're doing trb-i : in addition to 'tx is 1024 bytes, and block is 1024 tx' , consider another item: 'block MUST contain 1024 valid tx'

a111: Logged on 2017-01-17 00:21 asciilifeform: to possibly squeeze something useful from thread: as i understand, a lamport-based 'trb-i' ~could~ run on z80.

mircea_popescu: absent a good or at least workable breakthrough in this vein, there's no strong technological incentive to move to trb-i

mircea_popescu: yes, but the idea is to not expand the hipster doofus design principles to trb-i

mircea_popescu: the g has a decent debottler built in ; the trb-i does not, and needs a few.

asciilifeform: in given trb-i scheme, a block either exists on disk -- or does not

asciilifeform: to clarify -- in my mind, a 'trb-i' ~must~ be capable of checking validity of tx at wire speed (i.e. at the speed it is physically capable of receiving them) on reasonable iron.

asciilifeform: in turn it is also why i have an interest in a hypothetical nonbignumtronic (i.e. lamportronic) 'trb-i'.

asciilifeform: to possibly squeeze something useful from thread: as i understand, a lamport-based 'trb-i' ~could~ run on z80. ☟︎

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.

mircea_popescu: if we make the trb-i correct it should work like vtrons, multiple language implementations

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 )

BingoBoingo: I have a partially trb-icized 7 series in the name of implementation pluralism. No earthly idea what all changes happened.