18 entries in 0.303s
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.
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 mircea_popescu: this is at the core of the argument in favour of a
trb-i implementation.
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
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
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: 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