asciilifeform: wasn't that ^ thing simply an instance of 'i'ma put some coin on the floor for a miner to take' ?
asciilifeform: mircea_popescu: as in, 'fuck you, i won't relay this, your addr ends with my auschwitz tatoo number' ?)
asciilifeform: (if tx can be verified at line rate, nobody can do any more damage using tx flooding than they already can do by flooding your net pipe)
asciilifeform: though O(1) verification could make this a nonproblem
asciilifeform: aha, even with mandatorily expiring tx, it is still possible to flood at low cost
asciilifeform: afaik it is one of the only two known steps in that direction (the other being wotronics. and we discussed what a coin that relies ~solely~ on wotronics, and not at all on proof-of-work, might look like.)
asciilifeform: 'if you notice that the world hashrate seems to now equal what you could make out of your kitchen appliances, you are probably on cooknet'
asciilifeform: and isn't that what the proof of work thing was originally about..?
asciilifeform: perpetuum mobile is similarly 'needed'.
asciilifeform: 'if you keep banging head on glass, you are probably in a jar'
asciilifeform: i am at a loss as to how this problem is solvable in general case. aside from mircea_popescu's answer to my 'panopticon' thread, 'don't get caught in a jar!'
asciilifeform: there are as many 'bitcoin nets', theoretically, as there are nodes
asciilifeform: mircea_popescu: this is inevitable fact of life, boxes live and die, wires are cut, new ones -- laid, etc
asciilifeform: (see mircea_popescu's earlier point re imposing cooperation on castles)
asciilifeform: it seems like a terrible liability, for such a thing to be possible
asciilifeform: why is it necessary for anyone to know the global count of operating nodes
asciilifeform: what we afaik don't have is 'incentive for node-keeping' algo (though mircea_popescu's partially solves this, by requiring miners to have healthy nodes)
asciilifeform: to outline what we have so far : we've a 'must have all blocks' mining algo, from mircea_popescu ; we have a O(1)-verify-of-any-and-all-tx-and-blocks algo from asciilifeform (today) ; and we also now have a 'limited cpu cost for tx' algo.
asciilifeform: but this is an unlimited cheque, of sorts.
asciilifeform: and yes, the man in the besieged castle, would dearly love to broadcast an unexpiring tx, throw it in a glass bottle into the sea, and who knows, it will go to friendly lines
asciilifeform: yes but potentially never included, and always a cpu tax to all-comers.
asciilifeform: it is a 'to-allcomers' quantum of socialistronium
asciilifeform: in that nodes are required to contemplate it again, and again, potentially forever
asciilifeform: trinque, mircea_popescu : the reason for my 'want-block' gedankenexperiment, is the 'high vacuum' line of thought from earlier. because any way you cut it, an unexpiring tx is a kind of cheque for unlimited number of cpu cycles from the rest of the world
asciilifeform: this would abolish bbet-like 'dr.evil sat on this tx until convenient moment, then mined it' when desired.
asciilifeform: on second thought, it seems to me that you could get everything you could possibly want from 'want-block', by making an optional 'max-block'
asciilifeform: now let's work same example in hypothetical 'needs want-block'. there you would simply have to sign 2 tx, with same payload other than 'want-block', neh ?
asciilifeform: (the gavin-killing device from mircea_popescu's 'missile crisis' piece)
asciilifeform: doesn't that make setting up the temperature pump harder, rather than easier ?
asciilifeform: (the only alternative known to me, presently, is the matrix mechanics 'coin' we discussed on a few occasions, and that is 'martian' tech that nobody alive is necessarily qualified to operate )
asciilifeform: mircea_popescu: the unfortunate bit is that having global consensused state (blocks) at all, already does this
asciilifeform: trinque, mircea_popescu : to my naked eye, looks like you could get best of both world, by making 'want-block' optional
asciilifeform: (which, if you recall in classical bitcoin, is not easy ! withholding exists...)
asciilifeform: he has to know the actual best-block.
asciilifeform: which is why i won't even take a position on this , and leave it up to folx who actually worked this scenario in real life , e.g. mircea_popescu .
asciilifeform: if no canned tx permitted -- this is no longer possible.
asciilifeform: trinque: looser variant buys you 'i can give canned tx to my friend so he can move my coin to /dev/null when usg shoots me, but nowhere else'
asciilifeform: mircea_popescu: andresen h. paid for it for a reason!11☟︎
asciilifeform: (seems to me that the old dictum 'wait 6 blox' would still apply just the same.)
asciilifeform: the one tricky question i can think of is, how does it behave under reorg.
asciilifeform: scheme is a quite obvious one. but i bet if there is anyone whom this shoe pinches, it'll be mircea_popescu , he will tell us where.
asciilifeform: either verifies (again in O(1) !) or does not
asciilifeform: in given trb-i scheme, a block either exists on disk -- or does not
asciilifeform: locking problems (gotta add tx to index, in current trb, as aggregate -- but the only way to do that is to stop the world! like complete idiot -- every time there is a new block, to prevent situation where there is a partially indexed block available to incoming mempool tx verifier) disappear.
asciilifeform: in either hypothetical trb-i -- you no longer need a db. any db.
asciilifeform: ( but as i described, you can make it protocolically impossible, by demanding parent's hash )
asciilifeform: trinque: nobody makes you relay tx that has future want-block.
asciilifeform: likewise you can reject, in O(1), any tx input which attempts to make use of a future ( > current-height ) block.
asciilifeform: (reject, that is, from mempool candidacy)
asciilifeform: to revisit upstack -- if you have 'want-block' field, you can auto-reject (in O(1) !!) any tx that comes in having a want-block that is <= current-height.
asciilifeform: and transform the problem into 'how do we keep enemy from jamming the low level transport', which is solved by signed-packets (or mircea_popescu's variant, or similar.)
asciilifeform: this would abolish the 'epicycle' of 'how do we rate-limit crapola'
asciilifeform: to clarify -- in my mind, a 'trb-i' ~must~ be capable of checking validity of tx at wire speed (i.e. at the speed it is physically capable of receiving them) on reasonable iron.
asciilifeform: danielpbarron: if this is desirable -- then can use scheme as described. otherwise can also require ~hash~ of the antecedent of the wanted-block.
asciilifeform: and mempool contents would have natural lifespans, as they presently do not.
asciilifeform: no longer would idiotic concept of 'ahahaha you're trying to DOUBLESPEND!' be a thing.
