tmsr - Search: trb

600+ entries in 0.054s

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? ☝︎

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 .

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

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.

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 ☝︎☟︎

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: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)