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
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
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
☟︎ 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.
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.
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.
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)
BingoBoingo: Oh the Trump flensing knife lulz come out tonight, while still digesting
trb-i theory. What a time to be live!
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.
☟︎☟︎ 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.
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
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.