log☇︎
1200+ entries in 0.104s
shinohai: i more interested in rockchip now, because trb
phf: ah see the graph is misleading, because btcbase base grapher culls it. we've ran into similar issue back in the heavy experimental trb days, so one of the very first things that the btcbase distinguished itself on is producing a graph of possible presses, rather than pure antecedent/descendent. this was discussed and documented in the logs, in before "why you do that!1"
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.
asciilifeform: mircea_popescu: asciilifeform routinely misremembers having v 4y ago. prolly because we were already doing signed chains of patches since day0 of trb. hand-cranked v.
asciilifeform: i cut winblowz #ifdefolade out of trb because i did not read it and don't intend to.
asciilifeform: it is for this reason that asciilifeform cut most ( unfortunately not all, there is room for improvement! ) ifdefolade, out of trb.
asciilifeform: i abolished it in trb ( rotor ) , ave1 -- for gnat, and really ought to end with the logical conclusion, standard cuntoo musl/headers/gcc.
asciilifeform: there's no rsa in trb
asciilifeform: ( why? because asciilifeform doesn't like to crypto in any form, even as toy, on boxes without rng, and some of his trb dev machines at the time had none )
a111: Logged on 2018-06-26 17:45 trinque: could say we want trb to be exemplar of "how to V", in which case yeah, regrind it all
mircea_popescu: http://btcbase.org/log/2018-06-26#1829715 << nah, trb is the bulkiest and most dangerous item on the table, it utterly can't be the exemplar at this early stage. ☝︎
asciilifeform: the 'is it same trb' is much smaller problem than it seems, is quite resolvable mechanically ( as demonstrated in my http://therealbitcoin.org/ml/btc-dev/2018-April/000296.html experiment , for instance )
mircea_popescu: much better than having to resolve the "is it same trb" problem. what's the drawback ?
a111: Logged on 2018-06-26 17:13 trinque: so if there's a hero around that wants to take that on, we can start getting trb patches out the door again.
a111: Logged on 2018-06-26 17:02 ben_vulpes: heh, last time i took a crack at *that* i got mired in finding unspent outputs with trb
trinque: could say we want trb to be exemplar of "how to V", in which case yeah, regrind it all ☟︎
mod6: because if so, then we need a new trb genesis. which doesn't effect v in anyway, just another pita for trb.
mod6: i see ben's point, but i'd rather trb one whole thing, instead of a 'before manifest' and 'after manifest'.
mod6: i'll regrind the whole trb tree. however, I think if we -must- do this, we should only do it one time. and i really don't even want to do it at all.
trinque: so if there's a hero around that wants to take that on, we can start getting trb patches out the door again. ☟︎
ben_vulpes: heh, last time i took a crack at *that* i got mired in finding unspent outputs with trb ☟︎
asciilifeform: ben_vulpes: at one time i tried to implement more or less same item you're making, and did the shiva thing, and in the end thought that whoever it was ( mircea_popescu ? ) who suggested that trb should simply eat ( and prompt to sign ) raw tx, generated externally via scripts, was right
asciilifeform: ben_vulpes: funnily enuff, ~this very item~ is how asciilifeform got mired in attempt to bolt a lisp onto trb
asciilifeform: eliminate possibility of confusion with old , or reactor meltdown if new trb is plugged into a scriptolade harness meant for old, etc
a111: Logged on 2018-06-22 21:55 ben_vulpes: next thing i'm going to try is manually walk the spend-to-self down by 100 satoshis until this trb shits a tx out and then look at what it produces
mircea_popescu: mod6 backups are your friend! this whole trb stuff is a little friable.
mod6: i broke my trb blockchain.
mircea_popescu: if you try to send it with a lower fee than the level you set it to use it'll throw an error ; the rule for trb is to throw useless incomprehensible if not outright misguiding errors.
mod6: trb should just shit out a tx
ben_vulpes: i wasn't aware that it was 50ksat/byte, no, but nevertheless trb shouldn't even be aware of that. orthogonal issue, isn't it?
ben_vulpes: this is trb
mircea_popescu: is this trb ?
ben_vulpes: next thing i'm going to try is manually walk the spend-to-self down by 100 satoshis until this trb shits a tx out and then look at what it produces ☟︎
ben_vulpes: well this is a fuckin doozy; i'm trying to get trb to cough up a transaction that spends 0.00420032 to one address, 6.65784110 to another address, and spends 0.00021850 in fees, all of which my arithmetic pad shows summing to 6.66225992 btc, but trb complains of "insufficient funds". can someone doublecheck my maffs?
asciilifeform: ben_vulpes: trb is happy to ~eat~ anyonecanspendolade, just won't shit it
asciilifeform if it wasnt clear, highly disrecommends the continued use of shiva/tscheme for anyffing trb-related
asciilifeform: compared to, e.g., trb reactor dismantlement and rod replacement , re-creating the useful part of emacs is light work.
mircea_popescu: asciilifeform no but this is my point. "why are you using emacs when in fact trb will need ada scheme anyway and then you could just have a musl-gnat nerwmacs" ?
a111: Logged on 2018-06-21 16:08 phf: http://btcbase.org/log/2018-06-21#1828005 << the closest we got to a replacement i believe was asciilifeform's shiva, i.e. a tinyscheme embedded into trb runtime. it was suggested as a useful exercise for novices to attempt to expose existing, useful rpc function using it, but there were no takers. at some point the idea of using shiva in prod also went away, because tinyscheme is not necessarily production ready (primarily because of C-ism issues). as
mircea_popescu: but no, it's not like it's verboten to stand up a trb, god forbid.
a111: Logged on 2018-06-21 14:07 Mocky: I'm confused about trb rpc. Log search suggests for the first year+ of bitcoin foundation rpc was marked for death: http://btcbase.org/log/2016-02-28#1417175 but then there's dump / eat block based on rpc? Is this a new version of rpc, I don't see a new version announced on the mailing list. Can someone sum this up for me, I'm having trouble following the history.
phf: http://btcbase.org/log/2018-06-21#1828005 << the closest we got to a replacement i believe was asciilifeform's shiva, i.e. a tinyscheme embedded into trb runtime. it was suggested as a useful exercise for novices to attempt to expose existing, useful rpc function using it, but there were no takers. at some point the idea of using shiva in prod also went away, because tinyscheme is not necessarily production ready (primarily because of C-ism issues). as ☝︎☟︎
a111: Logged on 2018-06-21 12:37 asciilifeform: i solved this same problem for trb -- i.e. building 100% musltronic proggy with '9000' deps , on a conventional box
mircea_popescu: http://btcbase.org/log/2018-06-21#1827994 << yes but this won't likely work here ; the dependency tree is like 10x trb's. ☝︎
Mocky: asciilifeform, yes. I'm still wrapping my head around v. My understanding is attaching name and trust to every patch with an explicit dependence tree and build order. But I've not grasped the details yet, or used except to build trb, or understood the src
asciilifeform: Mocky: as you are prolly already beginning to understand from the l0gz, vtronics grew from trb work, which demanded 'measure not 7, but 7777 times, before cutting once', in the style of http://btcbase.org/log/2014-11-15#922644 ☝︎
asciilifeform: Mocky: even quite small changes to trb, typically get months ( sometimes yrs.. ) of discussion, testing.
asciilifeform: Mocky: trb , roughly speaking , is a legacy item, in the same way as the icbm targeting comp and similar. i.e. a museum piece that gotta be kept in working order, rather than 'sexy, new' thing bubbling with development
asciilifeform: Mocky: the rpc thing is ugly and there were experiments re replacing it ( e.g. 'shiva', scheme interpreter bolted on to trb ) but this took a back seat to moar pressing matters ( control of memory footprint ; sane sync behaviour; coupla other items ) and to this day rpc is still there.
Mocky: I'm confused about trb rpc. Log search suggests for the first year+ of bitcoin foundation rpc was marked for death: http://btcbase.org/log/2016-02-28#1417175 but then there's dump / eat block based on rpc? Is this a new version of rpc, I don't see a new version announced on the mailing list. Can someone sum this up for me, I'm having trouble following the history. ☝︎☟︎
asciilifeform: i solved this same problem for trb -- i.e. building 100% musltronic proggy with '9000' deps , on a conventional box ☟︎
asciilifeform: just like in earlier rotor-trb.
asciilifeform: just about errything that doesn't abuse some glibc-specific knob, runs 100% under muslism ( e.g. trb, which was the first proggy i personally built for musl, back in the http://therealbitcoin.org/ml/btc-dev/2015-July/000133.html days )
asciilifeform: situation quite reminiscent of bitcoin immediately prior to trb
asciilifeform: phf: this really calls for a ben_vulpes-on-trb-style archaeological dig
asciilifeform: by this logic could just as well omit trb from cuntoo
asciilifeform: ergo gotta have a trb-frozen emacs.
asciilifeform: ( granted, a defective 'replacement for trb' will give you a reactor meltdown, whereas a climacs-like abortion will simply create grumbling would-be users who revert back to emacsism )
asciilifeform: it's about on par with full replacement of trb.
asciilifeform: phf: slime aint exactly trb, it's, what, 50kB ?
asciilifeform: http://btcbase.org/log/2018-06-19#1826979 << phf i for one would not be opposed to 'rewind to 19 and patch as-needed', like we did with trb. ☝︎
asciilifeform: mircea_popescu: the best object of comparison is imho trb.
asciilifeform: thing is quite ripe for the trb treatment.
asciilifeform: e.g. trb genesis , weighed ~900K , not so far.
asciilifeform: mircea_popescu: pogo ? they're as usable as ever as soon as somebody gets trb into 256MB, lol
asciilifeform: and generally treasurer and instigator oughta be different people. as in the trb foundation.
asciilifeform: i did most of the early trb on that thing
asciilifeform: junkyard wars (e.g. trb, mp-wp) where one is stuck welding a tank from 5 zaporozhets and 3 lada carcasses, because that's what there is to work with, inevitably are heavyweight ☟︎
asciilifeform: trb is, what, 25k-loc.
asciilifeform: phf: trb is, what, 800kB, and already imho 'weighs' ~10+ yrs worth of study to fully grasp
asciilifeform: in other funnies: the preface in http://btcinfo.sdf.org/blog/trb-build-instructions.html .
lobbes: rned basics of v operation, stood up a trb node, and I don't plan to stop there. So what's your point?
asciilifeform: certainly nogood for trb.
spyked: http://btcbase.org/log/2018-05-30#1819855 <-- same here. and from what I understand, they're also planning to launch a RK3328-based board soon (announcement: https://olimex.wordpress.com/2018/01/16/a20-som204-and-som204-evb-preliminary-info-is-uploaded-on-our-web/ ). OTOH the specs look perfect for a ARM64-based trb machine. ☝︎
asciilifeform: ( c2 feels, to asciilifeform , even 'longer ago', epochally -- even such a basic thing as trb, say, did not yet exist )
trinque: and it'll still be a trb-sized genesis of a "found item"
trinque: eh, I wouldn't rely on him for that. he's yet to show any signs he's pressed a trb himself using the previous V
trinque: with those changes I was able to press trb with a ccl-built binary
mircea_popescu: for instance : bitcoinfs may be found useful by someone storing flac muzak. they'd then copy it from its original tmsr-os / trb tree, and put it in their gp-os / torrent tree.
mircea_popescu: but should eg, bitcoin-fs be written, then yes trb will exist in the same tree as bitcoin-fs. and should we go as low as tmsr-os, then yes, tmsr-os as genesis will have bitcoin-fs patchzone and then trb patchzone after that. and people wanting to use bitcoinfs for something else can just press up to there and no further. and projects wanting to import bitcoinfs but not trb will just build off that height of tree, and continue
asciilifeform: douchebag: you did ~only~ the minimal interpretation of what was asked. like a schoolboy. instead of, e.g., annotating this list with 'is this an actual vuln in actual physical trb'
asciilifeform: and i still don't seen any vulns in anything that actually gets linked to AND CALLED FROM trb
trinque: the intent here is to force him to make good on his word. earlier he said the rockchip was going to be a tool to get acquainted with trb, and now it's http://btcbase.org/log/2018-05-20#1815869 ☝︎
a111: Logged on 2018-03-29 00:21 trinque: great. I'd like you to review the dependencies of trb (which were frozen at particular versions) for known public exploits, and to publish a report of this on your own mpwp blog.
a111: Logged on 2018-05-18 03:50 trinque: http://btcbase.org/log/2018-05-17#1814596 << gave this a whirl, but press of trb's makefiles.vpatch says GnuPG failed to import key ".../wot/ben_vulpes.asc".
lobbes: tedious at first, but has already saved my ass on so many occasions (my trb install adventure, recently, for example)
trinque: http://btcbase.org/log/2018-05-17#1814596 << gave this a whirl, but press of trb's makefiles.vpatch says GnuPG failed to import key ".../wot/ben_vulpes.asc". ☝︎☟︎
mircea_popescu: trb, also, ball of cpp.
mod6: Once opon a time, the docs we put together for trb users to build a gentoo worked. Much better, and much more clear than the gentoo garbage docs.
mod6: I'm trying to build up two machines so I can do some trb testing with rawtx, et. al. Kinda hung until I can get an OS installed.
ben_vulpes: native bluetooth stack i'm going to guess does not affect trb build
ben_vulpes: douchebag: now how would one go about determining if any of these mines were steppable-upon or stepped-upon in the context of trb?
mircea_popescu: http://btcbase.org/log/2018-05-08#1811085 << minigame would host it ; so would deedbot. you saw the trb build style, specifically http://thebitcoin.foundation/trb-howto.html (the parts where it goes 'curl http://deedbot.org/deed-430460-2.txt > rotor.tar.gz.asc') ☝︎
trinque: this is a trb log, not some banthing I made
a111: Logged on 2018-05-05 22:01 ben_vulpes: trb on rockchip, lobbes ?
mod6: lobbes: great job on getting trb going, and on tying up all the ends so if anyone hits that same problem again!
ben_vulpes: trb on rockchip, lobbes ? ☟︎
lobbes: in other news, I have a trb node up now and eating blocks (thanks to mod6 for all his troubleshooting efforts, and asciilifeform for confirmation of suspicions)
asciilifeform: lobbes: http://btcbase.org/log/2018-05-05#1810194 << exactly it. your musl gcc never built, so trb has nothing to be built ~with~. you must find out why it did not build. but i recommend burning your heathen linux to the ground and using danielpbarron's, or trinque's, or mine, gentoo recipe ☝︎
mod6: so go to your trb machine, and then cd into : bitcoin/src