log☇︎
72 entries in 0.484s
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
shinohai: xpost for trb-ists: http://btcinfo.sdf.org/blog/trb-keccak-regrind-test-results-and-notes.html
mircea_popescu: diana_coman http://ossasepia.com/2018/12/19/a-week-in-tmsr-26-november-2-december-2018/#selection-105.764-105.817 << actually, a major bomb was dropped there, wherein long standing trb-immunity was revoked.
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 ☟︎
mircea_popescu: http://btcbase.org/log-search?q=from%3Amircea+trb-i << interesting list, at that.
asciilifeform: iirc was one of the moar recent 'trb-i' mircea_popescu threads
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: which is how trb-i even became an item.
asciilifeform: today - 'trb-i', ciphers of known strength, a few others.
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.
mircea_popescu: anyway, proper adatron -> trb-i -> fixed 2/2 txn model.
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?
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.
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: [BTC-dev] (CRACKPOTTERY) Notes re: one possible "TRB-I". ☟︎
asciilifeform thinks 'holy fuck is the trb-i article looooong;' who will have the strength, to read this.
asciilifeform writing draft trb-i spec
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: (a trb-i item )
deedbot: http://trilema.com/2017/trb-i-addressing-scheme-proposal/ << Trilema - TRB-I Addressing Scheme Proposal
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: in either hypothetical trb-i -- you no longer need a db. any db.
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.
mircea_popescu: trb-i, yes?
asciilifeform: i.e. 'trb-i'
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.
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: ( 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 )
deedbot: BingoBoingo rated shinohai 3 << Regular Qntra Contributor and TRB-ist
BingoBoingo: I have a partially trb-icized 7 series in the name of implementation pluralism. No earthly idea what all changes happened.