Results 1 ... 250 for 'trb'...

Results 1 ... 250 found in trilema for 'trb' | →

diana_coman: jfw: does the above mean that the "offline" part includes trb?

mp_en_viaje: it's one thing to say "well mister... no secure systems made before this date are practically useful anymore, because they must include this mb, and so it's practical to make NEW ones, including it". it is ANOTHER thing to say "your secure system must actually be always-on connected to a net interface and via trb at that"

ossabot: Logged on 2020-03-09 22:26:10 jfw: mp_en_viaje: do you have a specific goal in mind for Thursday's wallet work? Do you also want to use the online part (I would imagine so but could technically be done without)? If so, note that it takes about a day to scan the present blockchain once fed the address(es) of interest, and requires a TRB node. If you wish to also send the rawtx using it, as would be most proper, we'll also need that

mp_en_viaje: so it'd be fair to rewrite http://logs.ossasepia.com/log/trilema/2020-03-07#1959149 rather as "can i assume you have an x86_64 unixlike with no less than 64GB RAM, at least 1 TB HDD that must be SSD, at least two cores and, gcc. v, trb, curl etc, of which trb'd best be up to date" ?

dorion: http://logs.ossasepia.com/log/trilema/2020-03-12#1959477 - what do you expect to run on what you're building ? trb ? or is it a bridge too far since isn't required to boot, edit and rebuild ?

jfw: As for the private key, since as I understand you want to spend from an existing one imported from some other wallet implementation, I should note that it can be imported in hex or WIF format, however, as in TRB, "compressed" keys aren't presently distinguished. It's possible to use them through some code tweaks, though it's presently all one or all the other.

jfw: mp_en_viaje: do you have a specific goal in mind for Thursday's wallet work? Do you also want to use the online part (I would imagine so but could technically be done without)? If so, note that it takes about a day to scan the present blockchain once fed the address(es) of interest, and requires a TRB node. If you wish to also send the rawtx using it, as would be most proper, we'll also need that

billymg: http://logs.ossasepia.com/log/trilema/2020-03-01#1958703 << i have a strong feeling the reason it's *not* this, and the reason the mp-wp genesis is 7x the size of trb genesis by LOC, is because it was designed by the "no one user matters more than another" crowd

mod6: bvt: et, al. Still testing/debugging. Tried an experimental vpatch, didn't work. Going to make some changes and continue on. Here's the latest logs for the curious: http://www.mod6.net/wedger/mod6_wedger_test2.log http://www.mod6.net/wedger/trb_debug_wedgerpy_test2.log

mod6: bvt: et, al. Was able to use alf's wedger tool to replicate the problem. It took exactly 1 try. Here's my notes and debug.log (renamed) from the test: http://www.mod6.net/wedger/mod6_wedger_test1.log http://www.mod6.net/wedger/trb_debug_wedgerpy_test1.log

bvt: http://bvt-trace.net/2020/02/a-tiny-and-incomplete-trb-wedgetrace/#comment-139 - did some more debugging today, but cannot get a wedge when i do need it

feedbot: http://bvt-trace.net/2020/02/a-tiny-and-incomplete-trb-wedgetrace/ << bvt's backtrace -- A tiny and incomplete TRB wedgetrace

mod6: Heads up to TRB users, seems that nodes have wedged on block 618406. A simple restart of TRB seemed to resolve it. Not sure on the cause yet. Will update with more information as I have it.

ossabot: Logged on 2020-02-17 18:32:25 dorion: perhaps mod6 takes the lead to implement the clearsigned scheme on his keccak regrind of the trb tree.

dorion: spyked is rebuilding trb shortly, so if mod6 leads the way, followed by jfw and spyked that's at least 3 people scrutinizing the clearsigning scheme, tools and likely many of the same patches within the same timeframe.

dorion: jfw is expecting to finish the offline side of Gales Bitcoin Wallet this week, so his development plate will be clearing a bit. He has an unpublished patch to trb to simplify the build system on Gales, so checking/working with mod6 and getting his patch published could be his next priority. Among other simplifications

dorion: perhaps mod6 takes the lead to implement the clearsigned scheme on his keccak regrind of the trb tree.

dorion: http://logs.ossasepia.com/log/trilema/2020-02-05#1957911 - it occurs to me that trb could be a good testing/clarification ground for this because a) it's likely the most scruntinized V-tree to date and b) mod6, jfw, and spyked all have some work to do with trb these next weeks.

feedbot: http://blog.mod6.net/2020/02/three-trb-vpatches-for-testing/ << mod6's Blog -- Three TRB Vpatches For Testing

mod6: I appreciate the poking re things TRB.

mod6: TMSR Lords and others seem to publish all their code on their blogs, which, I think is fine. But my hang-up with allowing people to post TRB patches/seals on their blogs instead of sending them in is two-fold: 1) It puts it on me to chase these down. 2) Then I have to place them somewhere for long-term keeping anyway. As we've seen, people's blogs get rather large, hard to find things, or disappear complet

mod6: mircea_popescu: Ok, I have published my trb keccak regrind on the bitcoin.foundation site. It comes with the following: 1. Update to original genesis.vpatch - removes the UTF charater. 2. Added mod6_privkey_tools.vpatch (unchanged fro the original ML posting by myself.) 3. A manifest file. 4. I've also updated the howto document on thebitcoin.foundation.

mod6: Upon resoltion of the privkey_tools question, will happily add it to the current archive of signed Keccak TRB Vptaches.

mod6: http://blog.mod6.net/2019/01/trb-keccak-regrind/

mod6: Also, mircea_popescu, I do have the the entire trb tree (with exception of privkey_tools) signed and ready to go in Keccak. Has been since last January. I havne't been able to find a Lord who will double check my work though.

mod6: Anyway, I'm open to another discussion around the privkey tools vpatch. For what it's worth, I think TRB sorely needs it. But again, the whole discussion about the wallet.

billymg: mod6: been doing some testing with your privkey_tools patch and afaict everything's working as it should. i applied it manually after pressing the trb stable tree

ossabot: Logged on 2020-01-21 23:57:55 billymg: damn it feels good being in control of my time again. i spent the morning installing alf's dulap-gentoo on a lenovo E545 i picked up off ebay, plus some research into the trb setup i'll want for it. i then took a break in the afternoon to read the origin stories from jfw and dorion, both of which were inspiring/motivating (and i plan to continue with the background articles published recently on other blogs as well

billymg: damn it feels good being in control of my time again. i spent the morning installing alf's dulap-gentoo on a lenovo E545 i picked up off ebay, plus some research into the trb setup i'll want for it. i then took a break in the afternoon to read the origin stories from jfw and dorion, both of which were inspiring/motivating (and i plan to continue with the background articles published recently on other blogs as well

feedbot: http://bingology.net/2020/week-1-2020-review-wrestling-with-nsd-after-standing-up-trb-nodes/ << Bingology - BingoBoingo's Blog -- Week 1 2020 Review - Wrestling With NSD After Standing Up TRB Nodes

BingoBoingo: !Qlater tell mod6 If you are still updating the node list on the trb site I've got: 143.202.160.10 in Costa Rica, 88.80.148.58 in Bulgaria, 192.151.158.26 in Kansas, and 205.134.172.4 in AlfRack running and sync'd. First three running 99999 version number, last running 70001 version number.

dorion_road: http://logs.ossasepia.com/log/trilema/2019-12-06#1954419 << there are a couple layers to my thinking. the idea started from the basis that I'm compiling and installing the bios on whatever hardware I'm using using for a trb node, tmsr-pgp, etc.

snsabot: Logged on 2019-11-29 03:55:19 jfw: mod6, trinque or other TRB scholars: has there been progress toward raw transaction RPCs since http://therealbitcoin.org/ml/2018-April/000297.html ? I've written a getrawtransaction (in my queue to publish) but am in need of a sendrawtransaction for a split wallet I'm working on ( http://fixpoint.welshcomputing.com/2019/gales-bitcoin-wallet-spec-and-battle-plan/ )

jfw: mod6, trinque or other TRB scholars: has there been progress toward raw transaction RPCs since http://therealbitcoin.org/ml/2018-April/000297.html ? I've written a getrawtransaction (in my queue to publish) but am in need of a sendrawtransaction for a split wallet I'm working on ( http://fixpoint.welshcomputing.com/2019/gales-bitcoin-wallet-spec-and-battle-plan/ )

mircea_popescu: now, as to the putative customer approach : i dun specifically want to make a new os for every single app we come up with. i'd like to make one and be done with it, such that minigame can use it, trb can use it, everyone can fucking use it.

jfw: source tarballs, though there's a TRB too.

jfw: I've found it quite usable for things like trb node, airgapped gpg machine, basic VPS (though no LAMP stack presently)

mp_en_viaje: let it be until such a time we can find someone qualified to own it. same place trb is waiting, and so on.

mircea_popescu: the original trb work suffered from a massive aglomeration of -ev workforce.

mircea_popescu: i expect the principal problem of trb attempt was horrid management.

trinque: the main problem with such a project is how large it is. there were several folks on just trb, for a bit anyway.

asciilifeform: same goes for the trb users. (wai they not 'went over with comb' ~before~ ? it's what signing means. 'i understand what i'm signing.' )

mp_en_viaje: what about trb ?

hanbot_abroad: well...what about trb then, for instance?

asciilifeform: ( unrelatedly, noticed this morning that (for 1st time?) all the trb noades known to asciilifeform , are properly synced )

asciilifeform: the trb's been keeping up better than any i've operated to date, but would be unscientific entirely to say that 3d of it mean anyffin.

asciilifeform: ( there's diana_coman , ersatz-dulap hosting http://logs.nosuchlabs.com/log + bot, and a trb . )

snsabot: Logged on 2019-10-24 18:07:31 asciilifeform: unrelatedly : seems 213.109.238.156 is new trb noad, in kiev ? who built? seems to actually work, a++

asciilifeform: unrelatedly : seems 213.109.238.156 is new trb noad, in kiev ? who built? seems to actually work, a++

ossabot: Logged on 2019-10-23 19:59:48 asciilifeform: mp_en_viaje: if after all you dun need a znc , leave the thing switched on, i'ma reformat when next test pilot volunteers, until then will run trb , i want proper test of trb perf on apu1. but if you decide you want a znc, su znc ; znc -c will run promptistic configurator. then reboot, and you'll have it.

asciilifeform: mp_en_viaje: if after all you dun need a znc , leave the thing switched on, i'ma reformat when next test pilot volunteers, until then will run trb , i want proper test of trb perf on apu1. but if you decide you want a znc, su znc ; znc -c will run promptistic configurator. then reboot, and you'll have it.

asciilifeform: mp_en_viaje: item is general-purpose pilot box, plz feel free to mutilate any way you like. the trb is a copy of 'zoolag', can replace w/ own favourite build, or switch off, etc. there is a nearly full chain. znc is set to smoketest knobs, if using , must reconfig.

asciilifeform: mp_en_viaje: prepared, however, box, if still interested. runs trb and znc ( the latter w/ default config, presently logs into fleanode as 'pilotplant' and joins #a , can fill in yerself or switch off by removing the crontab ) on boot.

asciilifeform: for mp_en_viaja, i have the choice of 1) standard rk, cum znc 2) apu1 w/ 1gb samsung ssd, cum znc, and in fact prepared trb on it also.

diana_coman: spyked: I think it was initially tailor-made for trb really, hence the odd stuff.

BingoBoingo: asciilifeform: It came out in duffel run. Was on tiny box I flew in that held first pizarro www and dns server along with first pizarro trb node

mp_en_viaje: so no, i couldn't give less of a shit as things stand right now if ffa is "properly completed" or not ; nor if "more material" is made available as unqualified scribbles on trb code.

ossabot: Logged on 2019-10-08 21:58:34 mod6: There is a lot of work re: trb that does need to be done too. Another thing that was nagging at me... if we're to have a "university", we also need materials. And technical materials can be 'trb' coad itself; however, it might be cool to have an annotated source.

ossabot: Logged on 2019-10-08 21:53:52 mod6: I would like to see trb carry-on indeed. Now, perhaps, more than ever, is needed as a check against wild shitcoiners out there.

ossabot: Logged on 2019-10-08 21:52:11 asciilifeform: imho these are the fundamentals, without which all other adventures pertaining to trb (e.g. propaganda) are meaningless.

mp_en_viaje: yes, it'd have been perfectly fine to say, YEAR+ AGO WHEN THIS CAME UP, "well mp, maybe we don't do other things, but we have a donations program that's growing an average 0.2% per month, predicated on building trb nodes, which we do built, at the rate of ~one per quarter".

ossabot: Logged on 2019-10-08 21:51:32 asciilifeform: nao asciilifeform is no one in tbf. but will be sad if it comes to be the case that there is no tbf to fund emplacements of noades, curation of the ref. trb (incl. mod6's very fine build system) .

diana_coman: http://logs.ossasepia.com/log/trilema/2019-10-08#1942922 - certainly need materials and yes, I think mod6 would do a great job annotating the trb code and generally getting it moving again.

asciilifeform: for a novel 'trbi' is entirely uninteresting what or how did fucking openssl.

asciilifeform: but again this is only interesting if one's building a '100% trb-compat' in e.g. ada.

asciilifeform: is only relevant to people who want to build trb-compat. mechanism from ground.

asciilifeform: mod6: importantly, tho, most of this horror aint relevant to 'trbi'

mod6: Yeah, for TRB/TRBi to improve, or take form, one needs to fully comprehend what it is we have, this thing called 'bitcoin'.

asciilifeform: mod6: annotation of trb is a+++ Right Thing imho.

mod6: There is a lot of work re: trb that does need to be done too. Another thing that was nagging at me... if we're to have a "university", we also need materials. And technical materials can be 'trb' coad itself; however, it might be cool to have an annotated source.

mod6: For me, I won't have a fief to preside over, but maybe I'll still submit trb related work.

mod6: But alas, The Foundation has some greater goals than simply trb itself. TRB can be one facet of this, but new blood will need to take the ship in a direction of outreach.

asciilifeform: mod6: imho it is only because we have trb, that other meaningful work has what to breathe.

mod6: I would like to see trb carry-on indeed. Now, perhaps, more than ever, is needed as a check against wild shitcoiners out there.

asciilifeform: imho these are the fundamentals, without which all other adventures pertaining to trb (e.g. propaganda) are meaningless.

asciilifeform: nao asciilifeform is no one in tbf. but will be sad if it comes to be the case that there is no tbf to fund emplacements of noades, curation of the ref. trb (incl. mod6's very fine build system) .

asciilifeform: iirc at least 1 had a trb noad going on rk .

lobbes: even worse, I dun even have a working trb node

mp_en_viaje: trb node very fine tester indeed.

asciilifeform: incidentally network is down to 3, maybe 4, working trb noades, such as are known to asciilifeform .

mod6: It serves two functions: 1. tbf website, 2. trb node.

asciilifeform: diana_coman: he appears to know about asciilifeform's orig. fumigated gentoo .

asciilifeform: diana_coman: in recent years, asciilifeform's experience was 'trb-grade box is ~100 $ / mo just about anywhere' , so consistent with this.

asciilifeform: diana_coman: outta curiosity, were the btc receiver addrs they genned, trb-compat ?

asciilifeform: 49 € / mo. for e.g. trb box, aint bad, imho.

mod6: mircea_popescu: Ok Sir, just re-encypted to mp_en_viaje for ya; http://paste.deedbot.org/?id=wTRb

asciilifeform: already in the 'pogo' experiment we had a working 32bit arm trb. so i expect it is doable with existing toolchain for 32-under-64.

asciilifeform: dorion: at some pt we'll definitely want a properly 64bit trb on arm, so can use >4GB. thing is, currently there appears to be no arm64 box on the market that actually has >4GB.

snsabot: Logged on 2019-07-26 10:17:04 dorion: ty mp_en_viaje I am Robinson Dorion, the someone BingoBoingo mentioned had inquired about the rk. Plan is to sync a trb node there.

dorion: http://logs.nosuchlabs.com/log/trilema/2019-07-26#1925030 << I've managed to make progress on the rockchip trb build, but've not yet succeeded. Presently the status is:

snsabot: Logged on 2019-09-10 12:19:26 asciilifeform: not even any kind of new plague. mircea_popescu recall how we had to cut a buncha gifs etc outta pre-trb to bake the genesis.

asciilifeform: not even any kind of new plague. mircea_popescu recall how we had to cut a buncha gifs etc outta pre-trb to bake the genesis.

snsabot: Logged on 2019-09-06 21:47:39 asciilifeform: trinque: and then you gotta delete these ? what if you want the resulting link to remain clickable ?

asciilifeform: trinque: and then you gotta delete these ? what if you want the resulting link to remain clickable ?

snsabot: Logged on 2019-09-05 14:41:05 shinohai: Anyway, this morning's experiments show that esthlos V won't press trb correctly. Barfs on asciilifeform's numbered bitcoin vpatches, eg:

asciilifeform: BingoBoingo: nginx was an old heathen attempt to 'trb treatment' of apache by 'cut all the pieces i dun use' -- of 1 particular user.

trinque: asciilifeform: nope, my trb is in uy

asciilifeform: for thread-completeness -- if anyone has a trb that aint in my addnode ( the piz nodes -- already are in ) and would like it included -- plox to comment.

asciilifeform: anyone else running a trb w/ 'who-gave' -- invited to publish theirs .

asciilifeform: btw re trb : BingoBoingo et al : http://nosuchlabs.com/pub/trb/whogave_10_20_2018-8_31_2019.txt << almost 1y of 'who-gave' blox log .

asciilifeform: to formalize : asciilifeform's current hypothesis is that there is a thin 'tube' of trb-compat. nodes b/w pekin & trb orchestra. responsible for 100% of new blox.

asciilifeform: BingoBoingo: think, this is elementary. as soon as they issue a 'bloomism' or similar cmd to a trb node -- they get malleus'd. and yet we still get blox in realtime for 6-7 months at a stretch.

asciilifeform: before considering any such horror, rly oughta fix propagation b/w trb !!

BingoBoingo: I'm suspecting a lot of nodes on the intermediate PRB version numbers 0.8, 0.9, etc before peer-to-peer pki-ism are falling enough that we may have few bridges allowing communication between prb and trb

asciilifeform: the correct frequency with which situation 'trb node a is at height H, its peer trb node b is at H-k, for hour+' oughta happen, is ~never~

asciilifeform: BingoBoingo: yest.'s episode cemented in my head the insufficiency of my orig. 'aggression' patch. i strongly suspect The Right Thing is some variant of ben's. with the orig., node eats 5-10 blox when connects to trb peers on restart, then the connections stable and gets nomoar for hours. whereas on ea. restart, in facts gets the 5-10.

BingoBoingo: And it looks like we have consecutive days of TRB constipation 592597 has yet to enter the canon

asciilifeform: in re trb -- zoolag ~still~ chewing on a block (perhaps the genuine ..450, perhaps not) even nao.

asciilifeform: re further trb lulz : 24.93.104.14 spams liquishit blox at ~gb/s

asciilifeform: ( and, recall, when trb is verifying , all net processing grinds to a halt )

asciilifeform: BingoBoingo: quite likely, if you were to try an' reprocess that turd into a trb-edible block, you will end with a perma-wedged node.

asciilifeform: BingoBoingo: and indeed no one in known trb world seems to have ...450 just yet.

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

asciilifeform: girlattorney: trying to get trb box for 20 is rather like trying to get luxury automobile for 1000

asciilifeform: in most places, a trb-grade box leases for equiv. of maybe 100 $ (usa) .

asciilifeform: girlattorney: re colo -- talk with diana_coman , who has been surveying various colos. ( piz is pretty packed in re trb, has no fewer than 3 operating nodes . and really these benefit from being dispersed geographically, rather than concentrated in 1-2 cages ! )

asciilifeform: girlattorney: the major weak point is propagation from miners, who are living in own parallel chinese universe and between whom and trb there is a thick layer of garbage.

asciilifeform: girlattorney: most folks who know how to operate trb, have at least 1 public and some # of unadvertised nodes.

girlattorney: so as long as trb doesn't care about the peers, and there isn't a single point of failure (aka DNS and root servers) we are sound, correct?

asciilifeform: the more properly working trb nodes there are -- the less payoff to anyone for monkeying with their connectivity. at present in fact i do not know how many there are. not erryone bothers to advertise .

asciilifeform: girlattorney: observe that there is no attempt at authenticating peers in the existing trb. you could easily be connecting to washington's node when thinking yer connecting to e.g. mp_en_viaje's. at one time i published an experimental patch where can route to people you personally know via ssh pipes, but currently not in use anywhere afaik.

girlattorney: btw, after stripping out DNS on my important applications (such as TRB) my question now was about IP space assigned from IANA, could this be in the future an attack vector?

asciilifeform: girlattorney: were you able to make your trb node ?

asciilifeform: trinque: re clocks, at one time mircea_popescu suggested to use trb block as clock. but imho is of very limited use as clock, cuz not guaranteed to advance in any given interval.

asciilifeform: diana_coman: this aint even the most egregious example, there's trb patches ~by asciilifeform~ that have since been reground that iirc i haven't signed yet

asciilifeform: mircea_popescu: ftr my own measurements are wildly variant, i suspect the 3 ( 4? ) trb nodes are bursting and eating pipe

asciilifeform: to where retire ssd? if still 'worx', e.g. trb node. lappies. if end of life ? stoke furnace. ( see mircea_popescu's piece with furnace. )

lobbes: once this thing is up I'll probably be asking in #a (unless #mod6 still lives?) about doing a 'hot-start' with trb

lobbes: in other news, I'm in the process of provisioning a dedi server (for primarily a second trb node). I grabbed one with 2 512GB SSD drives. Now my question is: should I bother with RAID 1? Or will this just be stupid because they will wear at the same rate?

lobbes: meanwhile, I've been looking at some dedicated server options, primarily for a second trb node on a proper ssd, but I will stand up a 'production' copy of asciilifeform's logotron as well

asciilifeform: it is even possible that the pipe is to blame, i.e. the measurement is 'random' depending on how congested the pipe at piz on acct of e.g. the multiple trb noads sitting there

asciilifeform: i dun recall hearing any serious barf. ( and i think somebody still has a trb noad there )

snsabot: 1000 results for "f:ifeform f:escu trb" in #trilema

asciilifeform: !q s f:ifeform f:escu trb

a111: Logged on 2019-07-24 00:56 mod6: http://btcbase.org/log/2019-07-19#1923606 << This is a neat-o vpatch 'who gave', but it came in just after the 'NO NEW WORK IN SHA PLOX'; so there are a few like this that probably will go into TRB main Vtree once the Lordship reviews/audits the proposed Keccak TRB Vtree; perhaps possibly after TRB has a new home OS/environment.

a111: Logged on 2019-08-01 21:01 dorion: I have a trb node pressed to asciilifeform_aggressive_pushgetblocks.vpatch plus a local modification to add a new rpc. This node was was fully synced for a couple days, but has failed to verify block 588012.

asciilifeform: of erry 20 folx that ask re 'my trb stopped at block B', 19 problem is impatience.

asciilifeform: 0 to do with trb.

dorion: I have a trb node pressed to asciilifeform_aggressive_pushgetblocks.vpatch plus a local modification to add a new rpc. This node was was fully synced for a couple days, but has failed to verify block 588012.

dorion: http://btcbase.org/log/2019-07-27#1925151 << trinque as of ~20 minutes ago, deedbot tells me my !!balance is 0.0 and !!ledger is empty. however, the txn I made for this request was included in block 587568, which is 86 confirmations deep at present according to my local trb. do you see a problem on your end?

a111: Logged on 2019-07-29 01:57 asciilifeform: !Q later tell mod6 prolly oughta change that webchat link at trborg to go to your castle

asciilifeform: !Q later tell mod6 prolly oughta change that webchat link at trborg to go to your castle

dorion: ty mp_en_viaje I am Robinson Dorion, the someone BingoBoingo mentioned had inquired about the rk. Plan is to sync a trb node there.

mod6: http://btcbase.org/log/2019-07-19#1923606 << This is a neat-o vpatch 'who gave', but it came in just after the 'NO NEW WORK IN SHA PLOX'; so there are a few like this that probably will go into TRB main Vtree once the Lordship reviews/audits the proposed Keccak TRB Vtree; perhaps possibly after TRB has a new home OS/environment.

asciilifeform: i/o, however, is only ~4x slower than host's, so in fact one ~could~ run e.g. trb on it.

bvt: hello. i'll be traveling this week, the end result is supposed to be a working trb node; i don't expect that any other productive work will be done otherwise. bvt_away is the account that i may switch to during this time.

mp_en_viaje: http://btcbase.org/log/2019-07-20#1923917 << there was also a s.mg attempt where diana_coman tried to preserve all linux (in the manner of trb, naive speccing at the time). also fucking died, over explodig complexity (basically, there's no way to control for repetition, end up having to store GB-size^2)

mp_en_viaje: something that takes the filter of "i want trb, eulora but not blogotron" our of the long list of all things available and creates a local-tree out of the world tree, just for you. which is STILL a complete tree, and presses and string of vpatches and all ; but it is merely an aspect of the omnitree.

asciilifeform: 'golden age' of ben in re trb etc was when was in own shop .

asciilifeform: ( it was only then that even devised the algo, during thread w/ mp_en_viaje re 'trbi' )

asciilifeform: mp_en_viaje: frustratingly, i have the 'trbfs'. but grrrr gnat bugola

mp_en_viaje: which is why we're working on build toolchains and kernels and whatnot, in lieu of, eg, trbfs.

a111: Logged on 2019-07-19 13:34 asciilifeform: certainly has NOT 'stood in place since 2015' tho. i would not want to use the trb of '15 in preference to the current.

mp_en_viaje: http://btcbase.org/log/2019-07-19#1923602 << yes yes. i wasn't contemplating an indictment, i mearly meant, we, sometime cca 2015, discovered that any heavy lifting re trb gotta wait, for some terraforming work.

a111: Logged on 2019-07-19 14:57 mp_en_viaje: and yes, it included fucking bdb, as well as all sorts of stupid crap, which no, nobody swore to this very day ; not because nobody read, either. nor do i expect anyone will ever swear to bdb trb component.

asciilifeform: http://btcbase.org/log/2019-07-19#1923625 << was a sort of cheat tho, the genesis did not actually include bdb etc ~textually~ . so maintained illusion of 'trb is this 300kB of shitoshi'

asciilifeform: ( for n00bz -- trb was 'tank w/out treads' for, iirc, 1st 6+ months, until this )

asciilifeform: at one pt i thought same re asciilifeform vs. trb . ( then mp_en_viaje unwedged me , he had bdb notes , '14 )

mp_en_viaje: http://btcbase.org/log/2019-07-19#1923558 << hash reference is useless for this purpose, because of the very meaning of a hash -- you can't get the hashed source back out of it. the hash worked well enough for trb because ~everyone has ~all versions and so it's a narrow and well documented domain. the hash will not work (and, experimentally, in plenty of cases you weren't involved with, failed to work, because the domain is 2+ degrees of magnitude v

mp_en_viaje: and yes, it included fucking bdb, as well as all sorts of stupid crap, which no, nobody swore to this very day ; not because nobody read, either. nor do i expect anyone will ever swear to bdb trb component.

mp_en_viaje: all discussion to shock and surprise aside, this is the fuck exactly how trb genesis happened, too. nobody wrote a good one, just picked an actual one and genesis'd that.

asciilifeform: certainly has NOT 'stood in place since 2015' tho. i would not want to use the trb of '15 in preference to the current.

asciilifeform: thing is, trb is imho mature in re 'knobs' , the time nao is to ~cut~, slice an' dice an' replace with adaistic prosthetics

a111: Logged on 2019-07-19 05:50 mp_en_viaje: http://btcbase.org/log/2019-07-19#1923456 << yes but trb was last worked upon i dun even recall, 2015 ? when we decided we have to fix everything else first. in between then and now, medical science made some progress

asciilifeform: in fact, recall how trb 'chicken' genesis was a hand-cranked recipe, cuz had to delete binary gif turds etc and vtron of the time could not autodigest such deletion

trinque: we did exactly "here are the filthy deps we don't understand and will probably abandon" in trb, recall

mp_en_viaje: http://btcbase.org/log/2019-07-19#1923456 << yes but trb was last worked upon i dun even recall, 2015 ? when we decided we have to fix everything else first. in between then and now, medical science made some progress

a111: Logged on 2019-07-19 03:08 trinque: http://btcbase.org/log/2019-07-17#1923105 << I followed the same model for depwads that don't belong to the republic as was followed in the trb build toolchain.

trinque: http://btcbase.org/log/2019-07-17#1923105 << I followed the same model for depwads that don't belong to the republic as was followed in the trb build toolchain.

asciilifeform: the other side of the medal, is that a trb node spends only small portion of its life in initial sync.

girlattorney: as already told: i appreciate that TRB exist even if i still not able to using it. However reading logs when syncing has been a pain and i thought that mempool during syncing could create just overhead

asciilifeform: the 'reject peers sending garbage' mechanism is also mine. trb did not always have it. i submitted it for inclusion to mod6's flagship after determining that it results in substantially improved performance across the board (i.e. peers sending bloomism are, statistically, an unlikely source of the-next-block)

girlattorney: could be written on trb a feature that enable / disable mempool?

asciilifeform: i personally removed this nonsense, as 1 of the opening shots of trb story.

asciilifeform: girlattorney: 'discard excess' in trb algo is ANYTHING received when its antecedent is absent.

a111: Logged on 2019-07-16 12:52 asciilifeform: trb, unlike prb, does not accept blocks 'on credit' (i.e. ones for whom the antecedent block is not yet on the disk)

BingoBoingo: <girlattorney> but i could argue with this: when i do bootstrap a core node, it actually get fed from other core nodes << During initial sync trb wants to receive blocks in order while core will intentionally spray blocks out of order

BingoBoingo: Playing with the version string on a TRB node is the fastest and simplest way to change the sorts of peers your node encounters in the wild

asciilifeform: girlattorney: simple logical inference (there's a number of publicly advertised trb nodes; most of'em agree with heathendom re the height) points to : no, not 'only with themselves' dunnit.

girlattorney: i was asking about where a TRB node fetch the blocks, if all of the TRB nodes are only interconnected with themselves

asciilifeform: girlattorney: will still be banned by any working trb node, on acct of sending nonclassical protocol cmds (bloom filter garbage etc)

asciilifeform: girlattorney: post plz your last half MB or so of trb log

girlattorney: and the amount of writes that TRB does with or without swap is insane

girlattorney: It's almost like TRB telling me: you're too poor to spend your time trying running me, do something different in your time

girlattorney: so, tried with many attempts to restart TRB and hoping it could fully sync. No fucking way. And at every shutdown (with ctrl - c) always a painful writing process of at least 50 gb, taking 30 minutes or so

a111: Logged on 2019-07-17 14:56 mod6: I created one for ave1s musltronic tools (which won't fit the bill yet, because of circular dep. of GNAT), one for diana_coman's Vtools (which may not fit the bill 100% either, yet), and one for TRB.

asciilifeform: the other variant is to do a la trb, genesis e.g. 3.70.16 (arbitrary, happens to be what i had around during 1st test) and ~then~ cut, a la trb. but it is gargantuan , would make trb genesis look microscopic in comparison, viewing the genesis patch in e.g. phf's viewer will prolly crash most www browser..

mod6: The idea being, once we're moved over to cuntoo, using keccak vtools & a keccak trb vtree, then the Foundation can go back to discussion of various patches that have been waiting in the lobby for some time.

mod6: I created one for ave1s musltronic tools (which won't fit the bill yet, because of circular dep. of GNAT), one for diana_coman's Vtools (which may not fit the bill 100% either, yet), and one for TRB.

mod6: Recently, on workbench, I've been trying to build up TRB on cuntoo; and most recently (last month) dipping my toe into creating ebuilds.

asciilifeform: mp_en_viaje: doesn't require hand-hexing, since trb actually stores all blox, simply needs re-walk trigger

a111: Logged on 2019-07-16 22:25 mod6: Couple of other things that I wanted to mention quick, girlattorney: Just be sure to make frequent backups of your entire blockchain. Be aware also that TRB does not handle power-outtages very nicely as BDB can get corrupted; UPS and the like can help to mitigate this.

asciilifeform: http://btcbase.org/log/2019-07-16#1922900 << imho it is foolish to take down a trb noad (i.e. allow it to fall behind) simply to copy the db. the best backup for a trb noad is a 2nd, 3rd,... node.

a111: Logged on 2019-07-16 22:16 mod6: http://btcbase.org/log/2019-07-16#1922542 << There is a patch that is not part of the main TRB vtree that does this, but it'll have to be patched in manually. And it most likely would need to be "re-ground" to apply cleanly ontop of your current pressed tree. However, if we can find a time where we could work together on it, I might be able to help you get that part going.

mod6: Then when you start up TRB, you can do that like so:

mod6: One could connect a TRB node through a SSH tunnel (to a remote endpoint/host with a static IP) so you don't broadcast your IP.

mod6: Couple of other things that I wanted to mention quick, girlattorney: Just be sure to make frequent backups of your entire blockchain. Be aware also that TRB does not handle power-outtages very nicely as BDB can get corrupted; UPS and the like can help to mitigate this.

mod6: an issue the 'stop' command to bitcoind, wait until it closes properly, then start back up with -addnode for a handful of trusted nodes (see command in http://thebitcoin.foundation/trb-howto.html in section 0x23 or at the very bottom 0x0D), which should sync you the rest of the way pretty quickly.

mod6: http://btcbase.org/log/2019-07-16#1922542 << There is a patch that is not part of the main TRB vtree that does this, but it'll have to be patched in manually. And it most likely would need to be "re-ground" to apply cleanly ontop of your current pressed tree. However, if we can find a time where we could work together on it, I might be able to help you get that part going.

asciilifeform: there's a vacant rk, prolly adequate for anything short of trb node

asciilifeform: but -- cheap. and 2G ram/GB nic/sata/etc. potentially useful, for, as original poster , trb.

a111: Logged on 2019-07-16 12:29 girlattorney: asciilifeform that's something interesting: once (not now, a couple of days ago) i was able to get to the general height, thanks to a couple of restart that allowed me to get those last blocks (it seems that when TRB starts, always download instantly 10-15 blocks). Basically when it was at the network height (synced) it was also connecting to core

a111: Logged on 2019-07-16 12:52 asciilifeform: trb, unlike prb, does not accept blocks 'on credit' (i.e. ones for whom the antecedent block is not yet on the disk)

asciilifeform: girlattorney: which is why you want to advertise at least 1 of your nodes , in your fleet, publicly, to other trb folx

asciilifeform: girlattorney: the gold standard for 'is my trb node publicly reachable?' is : to connect to it from another trb node.

girlattorney: i hope so, cause i was starting to thinking that TRB getting stuck fetching the last blocks could because the local address

girlattorney: behind a nat there is no way to tell TRB to ignore the 1st addrLocalHost

girlattorney: when i ran TRB in a box with a public routable address, there also was the double addrLocalHost, but always with the same public routable address

girlattorney: yes, i'm able to connect externally, my question is: can i tell TRB to not announce my local address?

asciilifeform: for 'adult' trb node, you will want to route public ip to it

asciilifeform: no need to cross compile unless you're building for something too small to run gcc itself ( and chances are it won't run trb , if so small , as with 'pogo' )

asciilifeform: girlattorney: mod6's build system ( based on asciilifeform's earlier 2015 'rotor' (see logs) ) builds first a frozen-in-amber gcc & friends, ~then~ the depds (db etc) , ~then~ trb per se

asciilifeform: girlattorney: trb is more like kalashnikov than television set. i.e. can be made 'user friendly' only to a point.

asciilifeform: trb btw still retains the ancient mechanism where 'try to avoid connecting to >1 peer on same 24block'

asciilifeform: mp_en_viaje: this is easy to do, only rub is that there are already 3 ( 4? ) trb nodes at piz, all on 1 ip block, and sharing a quite modest pipe.

a111: 4 results for "cement trb", http://btcbase.org/log-search?q=cement%20trb

asciilifeform: !#s cement trb

asciilifeform: girlattorney: it is already rare for trb people to do 'cold start', usually they 'light smoke' from existing

asciilifeform: trb, unlike prb, does not accept blocks 'on credit' (i.e. ones for whom the antecedent block is not yet on the disk)

asciilifeform: ~95% of cpu cycles (as measured by asciilifeform in '16) of trb, is spend waiting for disk.

mp_en_viaje: girlattorney, so wait, is this delayed trb running on a vps or on its own colocated box ?

asciilifeform: that's the gold standard, yes, physical box, w/ ssd, running strictly trb, and on serious (preferably industrial, but top-of-class residential fiber also worx) pipe

asciilifeform: girlattorney: trb on public toilet 'vps' hosting is generally a nonstarter

asciilifeform: girlattorney: in my experience, trb (with my 'aggression' patch) syncs from 0 in roughly 3wks, on a decent (fiber) pipe. however, last did this yr+ ago, and unsurprisingly the interval will only ever increase, as the chain gets heavier (on avg., grows 1000000 bytes erry 10min, recall)

asciilifeform: girlattorney: i attempted to bake exactly such in '14 , but the iron wasn't there yet ( we got a large supply of certain arm box, but only 256MB of physical mem, and only ~then~ found that without a total rewrite, trb cannot be sat down in 256M or even 1G )

girlattorney: in a near future i think that it could have sense to have a TRB marketplace, where you can buy your ready-to-deploy box

asciilifeform: girlattorney: trb is its own backup, think about it

asciilifeform: girlattorney: in my flagship trb box, i found that 1T samsung ('standard', rather than 'pro', not yet tested 'pro' series) ssd runs for just short of 2yrs prior to write cycle exhaustion

mp_en_viaje: trb does not need (and does not much benefit) from swapping.

asciilifeform: disable swap; i have found that on 2GB+ boxen trb , despite heavy mem fragging, will not overrun 2GB

asciilifeform: girlattorney: trb (for time being) retains the classical 'ask peers for new peers' mechanism, so unless you hand-curate the peers (most trb folx do) you will inevitably connect to garbage nodes at the statistically expected rate

asciilifeform: if you were looking at linux disk stats, you may have box with swappism enabled. (or do you actually have a 8TB drive, that trb somehow filled ?!)

girlattorney: asciilifeform that's something interesting: once (not now, a couple of days ago) i was able to get to the general height, thanks to a couple of restart that allowed me to get those last blocks (it seems that when TRB starts, always download instantly 10-15 blocks). Basically when it was at the network height (synced) it was also connecting to core

a111: Logged on 2019-07-16 12:07 girlattorney: if it could interest, from 0 to block 584k, TRB has written to disk almost 8 TB

asciilifeform: http://btcbase.org/log/2019-07-16#1922523 << trb doesn't ignore, the (prb-powered) 'blockchain sites' ignore.

a111: Logged on 2019-07-16 11:27 girlattorney: if it's just an ip + port it can be a "fake" node. What interest me is the fact that TRB seems to ignore the nodes with a user agent different than "therealbitcoin.org:0.8.88.88". I even tried to just have a "addnode=*corenode" and in some odd way it finds a way to communicate only with the TRB nodes

girlattorney: it's an arm board with a sata slot, so i can attach a 1TB ssd and let TRB running for a couple of years

girlattorney: mp_en_viaje i know a little bash, i used to compile bitcoin core until knowing TRB and my project would be to compile TRB for an arm board, to eat less energy than my PC (the ARM board would be an hardkernel Odroid hc1)

deedbot: asciilifeform rated girlattorney 1 << trb n00b / new blood

asciilifeform: !!rate girlattorney 1 trb n00b / new blood

a111: Logged on 2019-07-16 10:44 girlattorney: hi, thanks for voice, i'm here to ask about trb. Installed it on my PC, and after 28 days almost synced. Then it happens the following: when TRB is almost at the current height (as now, 585,647), it stays back a few blocks, like now that is at 585640, and just cannot catch the latests blocks

mp_en_viaje: there's probably some room for optimization wrt disk usage ; but that's rather wating for the more comprehensive trb-fs thing

girlattorney: if it could interest, from 0 to block 584k, TRB has written to disk almost 8 TB

girlattorney: if it's just an ip + port it can be a "fake" node. What interest me is the fact that TRB seems to ignore the nodes with a user agent different than "therealbitcoin.org:0.8.88.88". I even tried to just have a "addnode=*corenode" and in some odd way it finds a way to communicate only with the TRB nodes

mp_en_viaje: well, for you there's then no answer to the "how do trb nodes get blocks" question you had.

| →