asciilifeform: where is then the 'pile' ?

asciilifeform: at no point did asciilifeform make a physical 'pile' to determine the correct answer, it was arrived at on paper, with pen

asciilifeform: the choice is constrained by the peak & avg. drains of the other components

asciilifeform: asciilifeform, drawing up FUCKGOATS, had to pick what voltage regulator to use, they come in wide variety of max & peak voltage and current ratings

asciilifeform: let's take concrete example,

asciilifeform: in what sense does 'pile' in this construction not equal to what other folx mean when they say 'plan' ?

asciilifeform: mircea_popescu: say what means 'pile up all his materials' plox

asciilifeform screws in brand-new gas mask canister

asciilifeform: fails because did not pray to vishnu correctly ?

asciilifeform: why does he fail, if not from refusing to agree to a verifiable expectation of correct function ?

asciilifeform: then mircea_popescu's 'serious engineer' includes docker rat

asciilifeform: what does 'serious engineer' even mean, if not 'cares about this'

asciilifeform: at the design stage, there is an expectation, engineer knows in advance that if the thing buckles under any number of tanks that its surface might contain: stalin will shoot him

asciilifeform: shifting from a conceptual to a present 'this is the bridge you have, motherfuckers, drive' is dirty thinking.

asciilifeform: that's called an african pile of shit, or, charitably, 'junkyard wars' contest. not engineering.

asciilifeform: bridge holds 100 tanks indefinitely, or 500 for 30 minutes. is an expectation.

asciilifeform: failure is not a defined concept absent expectations.

asciilifeform: y'know, as in http://btcbase.org/log/2017-03-08#1623271 ☝︎

asciilifeform: 'oh i'll grunt and -- come what may !'

asciilifeform: engineering without expectations is not detectably different from taking a shit and other excretory exertions

asciilifeform: not argument against; but for realistic expectations.

asciilifeform: per dijkstra's 'tests reveal presence of bugs, but never their absence'

asciilifeform: liquishit that tests to spec is still liquishit.

asciilifeform: mircea_popescu: i was attempting a nonretarded trb-fs.

asciilifeform: http://btcbase.org/log/2017-03-11#1626033 << noshit! but it can only happen in trbi ☝︎

asciilifeform bbl, meat

asciilifeform: (the 10,000 + overhead, rounded to nearest cylinder.)

asciilifeform: these can be the fs 'block'.

asciilifeform: however ! looks like we ~do~ have a fixed-size element: the script.

asciilifeform: (there is no way to demonstrate the destruction of coin in any permanent way, so this tx will remain relevant for so long as bitcoin marches along)

asciilifeform: pruning ain't a thing

asciilifeform: (when gavin et al made 'brainwallets' seeded with common dictionary words, by the megatonne)

asciilifeform: from the original spamwave

asciilifeform: pretty obvious spamola

asciilifeform: ty mircea_popescu

asciilifeform: ooh nice

asciilifeform: do you happen to recall in which block?

asciilifeform: lol

asciilifeform: large, but nowhere near block

asciilifeform: how much did that weigh

asciilifeform: massive as in, most of a block ?

asciilifeform: when didja last measure this mircea_popescu ?

asciilifeform: (2+ standard dev, say)

asciilifeform: how many 'elephants' ?

asciilifeform: what's the statistical distribution of tx sizes, gotta wonder

asciilifeform: fixed bottles.

asciilifeform: ('child', 'woman', 'man', 'elephant' say)

asciilifeform: one possible solution is binning

asciilifeform: otherwise, as mircea_popescu said, nodice.

asciilifeform: phf: no, see, you gotta know max size to make array.

asciilifeform: mircea_popescu: if you haven't guessed, i have an incomplete one here (currently calling in my head 'nqb', 'not quite bitcoin') and was trying to adapt it to the very simple task of eating the existing blocks and parsing out the tx.

asciilifeform: and it is possible to compute a mintx.

asciilifeform: because block header tells us tx count.

asciilifeform: now on the other hand, it may be possible to calculate max tx size IN GIVEN block

asciilifeform: this is pretty monstrous, it means that if you want no-heap (proper adatron) handling of tx, you gotta preallocate 1MB for EVERY SINGLE ONE when reading'em

asciilifeform: and any other size you want, below that.

asciilifeform: (and given that the scripts can be -- each -- individually anything up to 10000 -- you can have, theoretically, 1MB tx)

asciilifeform: where i is the number of inputs, and o -- of outputs.

asciilifeform: the equation i've come up with, is --assuming all scripts occupy their maximal size, 10000 bytes-- : 14+i*(10043)+(10011)*o

asciilifeform: ( for a certain purpose i need to calculate the max bytefootprint of a tx )

asciilifeform: anybody know where ? or are they capped strictly by the block cap

asciilifeform: unrelatedly, i have combed trb src for a cap on tx input and output maxima, and found none

asciilifeform: ah in usa for some reason these called 'sybian', after one common brand

asciilifeform: hybrid

asciilifeform: looks like american mailbox , or nazi crematorium, hybdir

asciilifeform: behind

asciilifeform: nono

asciilifeform: on the pvc pipe legs

asciilifeform: lol what is that device

asciilifeform: tru!!

asciilifeform: if predecessor indexing is done by height, rather than hash

asciilifeform: how would you disqualify it for dblspends ?

asciilifeform: if 'at least', the degenerate case wins, i can qualify a block as the successor to itself

asciilifeform: but yes

asciilifeform: ~exactly~ N, not 'at least'

asciilifeform: and yes.

asciilifeform: consider, for instance, instead of difficulty zeroes, you simply must match N bytes of ~previous~ block's hash.

asciilifeform: there is also the possibility of not doing the idiot growing-string-of-zeroes method for difficulty growth

asciilifeform: but with different nodes having entirely different pictures of history, depending on which one they saw first

asciilifeform: you then can have forklets ~merge~, topologically, into what appears to be 1 chain

asciilifeform: bifurcation of ~block~ is even more interesting picture

asciilifeform: aha.

asciilifeform: as i currently understand, both x and y would have to be valid tx, for anything to happen (if y is invalid, it will not be mined).

asciilifeform: mircea_popescu: the obvious interesting sequel to the q, is what would be the first symptom of a colliding pair of tx having been fired.

asciilifeform: just as i described for 'tx vs larval-tx' disjunction.

asciilifeform: ^

asciilifeform: ditto blocks, it is retarded for their hash to uniquely identify them for other calculations

asciilifeform: (i.e. by hash of antecedent, rather than by where-it-is-in-blockchain)

asciilifeform: which is one of the reasons why shitoshi's nonpositional tx indexing is retarded

asciilifeform: mircea_popescu: that's what i ended up concluding

asciilifeform: mircea_popescu: same q can be asked re block hashes

asciilifeform: phf: i suppose the correct term would be 'orphaned' patches

asciilifeform: and the pair -- broadcast

asciilifeform: mircea_popescu: i did not say that it is easy to find. but would like to know the consequences of one being found.

asciilifeform: phf: how did those end up existing ?

asciilifeform: given that a tx is >256bits long, these pair necessarily exist.

asciilifeform: mircea_popescu: all you need is an x, y, x!=y, where sha256(sha256(x))==sha256(sha256(y)), and x is a valid tx

asciilifeform: nobody but mircea_popescu , hence the q

asciilifeform: mircea_popescu: unrelatedly, didja ever calculate what would happen to trb (or for that matter prb) if one were to produce a colliding txid ?

asciilifeform: mircea_popescu: the hilarious bit is that prb munged up the script system beyond recognition, BUT they kept this turd! merely moved it, http://btc.yt/lxr/satoshi/source/src/script/interpreter.cpp?v=0.10.0rc4#0256