asciilifeform: mircea_popescu: should hope so. because 100mb ain't enuff for even 1 trbtron

asciilifeform: BingoBoingo: what was yer bandwidth, again?

asciilifeform: asciilifeform's point was not 'don't turn', but 'gotta turn them knobs independently of one another, or 9000 years will not suffice'

asciilifeform: and as 'ship is made to sail', knob -- is made to turn.

asciilifeform: trinque: item very much deserves proper test.

asciilifeform: aha , ^ is how i came up with the value

asciilifeform: incidentally when i wrote the versionknob patch, i did not expect that everyone here will run with ~same~ , default ver

asciilifeform: i'ma produce it this weekend, if no one else has.

asciilifeform: another patch experiment whose time imho has come, is 'prod' rpc command : trigger the boot sync behaviour at arbitrary time.

asciilifeform: aha

asciilifeform: needs a patch.

asciilifeform: you gotta compare without reset tho.

asciilifeform: iirc recent prb ( as analyzed by jurov, still digging for the thread ) will simply drop you if you connect and report <0.7 .

asciilifeform: trinque: that knob is there, to be turned. i've no argument that 'version dun matter', it may well matter. but oughta be tested correctly, as indep. variable.

asciilifeform: troo!

asciilifeform: if it in fact has become impossible to get a tx out without emulating all of prb, we have a Problem

asciilifeform: why should they get to filter us out by doing e.g. 'nothing below 0.7 can connect'

asciilifeform: trinque: this is not wrong , but it's a pov that concedes to the powerrangers the privilege of owning version#s

asciilifeform: mats: hand-feeding always works, yes. but it's not a practical means of keeping a node up in regular practice.

asciilifeform: what's btcwire ?

asciilifeform: and i'm satisfied that i found the reason for it. ( and no i do not have a ready pill, the ~algo~ is broken )

asciilifeform: trinque: the 1 common thread in asciilifeform's lab notes from birth of trb to today, is that once they fall behind, they stay behind, until reset. (often more than one reset.)

asciilifeform: ( see the massive log turd earlier )

asciilifeform: it isn't 'some noise', mircea_popescu , reset triggers the one and only sync-catchup routine

asciilifeform: after certain # of shots

asciilifeform: then could genuinely say 'it wasn't the reset, it was version mask'

asciilifeform: trinque: one way to turn this into an experimental setup would be to make ver knob adjustable ~without reset~

asciilifeform: ^

asciilifeform: one useful item would be a 'from whom this came' log prefixer patch

asciilifeform: but did not see , e.g., 'did 7 resets with 9.999... but only the 8th, with 50400, did the trick'

asciilifeform: what i saw was http://btcbase.org/log/2017-12-21#1755777 ☝︎

asciilifeform: trinque: ( and this is not specific to this case ) plox to describe, in pedantic detail, the events

asciilifeform: trinque: hm plox to expand then ?

asciilifeform: much of what the 'power rangers' did to their bitcoin, was an elaborate dance around this problem, with a dozen pseudosolutions that guzzled memory, and -- more importantly -- destroyed the integrity of their sync ( the orphanage bullshit, the headers-first bullshit , etc )

asciilifeform: because it is imho a major open problem .

asciilifeform: apologies for the clutter, but this item really ought to live in the permarecord.

asciilifeform: http://btcbase.org/log/2017-03-04#1621894 << see detailed discussion. ☝︎

asciilifeform: }

asciilifeform: return true;

asciilifeform:

asciilifeform: pfrom->PushGetBlocks(pindexBest, pblock->hashPrevBlock);

asciilifeform: if (pfrom)

asciilifeform: // Ask this guy to fill in what we're missing ☟︎

asciilifeform:

asciilifeform: printf("ProcessBlock: BASTARD BLOCK, prev=%s, DISCARDED\n", pblock->hashPrevBlock.ToString().substr(0,20).c_str());

asciilifeform: {

asciilifeform: if (!mapBlockIndex.count(pblock->hashPrevBlock))

asciilifeform: // If don't already have its previous block, throw it out!

asciilifeform: 2) inside the bastardry handler, in ProcessBlock(...) :

asciilifeform: the very FIRST connected peer who issues 'version' gets asked to help sync. and when THAT connection breaks -- that's it.

asciilifeform: }

asciilifeform: pfrom->PushGetBlocks(pindexBest, uint256(0));

asciilifeform: nAskedForBlocks++;

asciilifeform: {

asciilifeform: (nAskedForBlocks < 1 || vNodes.size() <= 1))

asciilifeform: (pfrom->nVersion < 32000 || pfrom->nVersion >= 32400) &&

asciilifeform: if (!pfrom->fClient &&

asciilifeform: static int nAskedForBlocks;

asciilifeform: // Ask the first connected node for block updates

asciilifeform: 1) inside if (strCommand == "version") { .... that is , command processor for peer's commands :

asciilifeform: the ONLY 2 times PushGetBlocks is called ( i.e. to explicitly ASK a peer for new blocks ) is :

asciilifeform: i'ma put this in the l0gz, ftr :

asciilifeform: so trinque , yer node synced on account of being reset. as in more or less every previous case of 'my node stalled, i changed knob K, and reset, and bam! , synced , knob K must be reason' -- it's the reset.

asciilifeform: + http://btcbase.org/log/2017-03-04#1621865 , and really whole thread worth reviewing. ☝︎

asciilifeform: concretely : http://btcbase.org/log/2017-03-04#1621858 ☝︎

asciilifeform: aside from brief period at bootup, a trb node DOES NOT TRY TO SYNC AT ALL, passively waits for someone to come and feed it. forever.

asciilifeform: http://btcbase.org/log/2017-12-21#1755775 << i dug into this item last yr, and found that the version thing is mostly a red herring : when you set 50400, the same derps drop ~you~, a millisecond or so sooner than you would've dropped ~them~ via malleus. the real culprit is always http://btcbase.org/log/2017-08-23#1702558 . ☝︎☝︎☟︎

asciilifeform: out of curiosity, what is the context for the http://btcbase.org/log/2017-12-21#1755741 problem ? ☝︎

asciilifeform: http://btcbase.org/log/2017-12-21#1755730 << africans have problems talking ?! ☝︎☟︎

asciilifeform: same reason why normal kbd is great, while 'virtual' is agony

asciilifeform: http://btcbase.org/log/2017-12-21#1755692 << think about it: no need to look at screen ☝︎

asciilifeform bbl

asciilifeform: fuck t9.

asciilifeform: i'd buy a pnoje that supports... morse input

asciilifeform: astonishing how such elementary feature is unknown today. i.e. 'NO ring unless one of numbers N1, N2, ... Ni'

asciilifeform: i was buying one, for someone else, not long ago, and ended up with ye olde 'razr'

asciilifeform: apparently none made in ~decade

asciilifeform: speaking of this, anybody know of a 'dumb' pnoje that has whitelists ?

asciilifeform: forget the street maps, speaking of raw photo

asciilifeform: ( and the oblig. terrain-tracking icbm... )

asciilifeform: there's no particular reason why one couldn't put it all on sd card and make passive pocket maptron.

asciilifeform: primo use of a good spam-ip farm

asciilifeform: for offline use.

asciilifeform: on subj : asciilifeform also wonders if anybody's 'liberated' google et al's spysat jpgs

asciilifeform: neato, notbad

asciilifeform: something like interlisp's structureeditor, perhaps

asciilifeform: phf: i've always wondered if it is possible to make a 'programming toy' proggy for touchpnojes that actually makes productive use of the fingers , rather than torturing user with simulated kbd

asciilifeform: that makes moarsense.

asciilifeform: aa sorta how asciilifeform sometimes travels with a hp48

asciilifeform: ~for~ it, i can even picture, nintendomarket, etc. but ~on~ ?!

asciilifeform still doesn't get why one would program ~on~ ipnoje

asciilifeform: yea i missed this

asciilifeform: ben_vulpes: why wouldja give all of the monkeys one shared key?!

asciilifeform: who the fuck 'backs up' per-luser pw.

asciilifeform: why would the admin want to back it up ? if luser luses his pnoje, he goes to beg and be issued new code, neh

asciilifeform: ben_vulpes: naturally they'd rather lusers not have 'lift the seekrit out of the pnoje' button, or they'll push it and write on postitnote

asciilifeform: only ever encountered google's variant of this idiocy

asciilifeform: i had nfi this existed

asciilifeform: '...Accepting or rejecting this phenomenon marks a fundamental divide between those who believe that words create reality, versus those who believe that objective reality exists and operates independently of how we happen to speak and think about it.'

asciilifeform: '...this linguistic battle is inherently non-winnable, as can be seen from how every term that was originally meant to be non-offensive, such as “moron”, “retarded” and “imbecile”, always became a schoolyard insult in short order. ... This is inevitable because the underlying reality that these words refer to is horrifying, and everyone can see how bad it would be to get hit on the head ...'