asciilifeform: so it merely needs to get mined again.
asciilifeform: davout: it would not, because A is not 'marked spent', it does not exist in the index at all after the reorg.
asciilifeform: davout: correct, but only tells half of the story. it is unspendable in the sense that whoever mined the original A, is left to be sad. but A can be reintroduced now. and with it, all of the tx that used it as an input.
asciilifeform: if you can re-introduce an old coinbase -- which you can , if it has been spent, per trb rules -- you (or anyone else) can afterwards reintroduce any and all tx that had that coinbase as an input
asciilifeform: in fact, studiously avoids doing anything.
asciilifeform: and wuille's thing does 0 against it.
asciilifeform: davout: as i understand, the attack described in 7th paragraph, with the transplanted tree, would still work today.
asciilifeform: looks like it describes exactly the scenario in this thread. and wuille sat down with his handler and asked, 'how do we 'solve' this but without actually solving it? hmm'
asciilifeform: because it was built by somebody who was dropped as a baby, and uses tx id as if it were guaranteed unique, then turns around and 'oops, they aren't, but it doesn't matter Because Reasons'
asciilifeform: davout: definitionally not, bitcoin has marvels such as being able to annihilate a coinbase from tx index using a (local! nobody but your node has to see it) reorg.
asciilifeform: simply by not catering to the patently idiotic expectation of being able to spend the output of a tx that hasn't been mined yet.
asciilifeform: and yes that means they have to live in a block, that you're reasonably sure won't be orphaned.
asciilifeform: davout: right ! want to make a tx ? know the indices of the outputs you're using.
asciilifeform: ^ likewise it is unclear to me why to even have a merkle tree, and not hash the tx one after another. but that's a separate thread.
asciilifeform: (which would only be calculated for the merkle root, and for no other purpose)
asciilifeform: with the difference being, that you can ONLY refer to a position in an existing block, and never to a tx hash.
asciilifeform: you can do it with a system otherwise identical to traditional bitcoin
asciilifeform: davout: it doesn't even require the cask scheme
asciilifeform: unfortunately , per grandfather's pistol , a tx ~in~ a block can spend the output of another, in same block; so verification of block tx is O(N^2) but the N is the count of tx in the block.
asciilifeform: trb, i will note, already will not relay any attempt to spend anything not already in a block.
asciilifeform: it is retarded and makes for 'orphanages' and O(N^2) verifications.
asciilifeform: if you had to write, e.g., (91722,1,1) instead of (e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468, 1) to spend an output -- none of this would be a thing.
asciilifeform: astonishing how much retardation flows from this one little turd, the use of hashes (rather than positions) as tx pointers.
asciilifeform: it's a textbook mircea_popescuan tv-raft. 'can't fix the problem, That Would Be Wrong, have a raft made of your tv to float on;
asciilifeform: 'Fully-spent transactions are allowed to be duplicated in order not to hinder pruning at some point in the future. Not allowing any transaction to be duplicated would require evidence to be kept for each transaction ever made.'
asciilifeform: what's a bezzle if not a sky held up by invisible column of farts and nobody-would-think-of-plane-as-rocket.
asciilifeform: btw this thread is unpleasantly reminiscent of , e.g., asciilifeform's conversations with his elderly parents , re thebezzle. 'look outside, sky not fallen, not moved a centimetre, you idiot'
asciilifeform: it is going on the conveyor mircea_popescu .
asciilifeform: ^ this is a question that can be answered exactly , using a patched trb
asciilifeform: can't show provenance for all unspents.
asciilifeform: you just have a 'i can't believe it's not bitcoin' rather than bitcoin.
asciilifeform: this could, potentially, account for some wedges observed in the wild. in theory.
asciilifeform: (will not accept a block where they are spent)
asciilifeform: it would instead manifest as one or more chains of tx that a trb node -- a particular one, that saw the particular magic orphan -- mysteriously does not want to spend the outputs of.
asciilifeform: the imho most tickling part re the hypothesis, is that the symptom would not necessarily leave any permanent sign in the mainchain blockchain
asciilifeform: iirc ben_vulpes set up a similar experiment ( lan miner ) a month or so ago, but i dun recall what came of it☟︎
asciilifeform: now for the practical consequence. what this means, as far as i can tell, is that there can exist -- may already exist -- chains of tx in trb, that cannot be walked back to a coinbase.
asciilifeform: because their parent coinbase gets zapped from the index illegitimately
asciilifeform: the result is an arbitrarily long chain of beheaded tx
asciilifeform: so nobody needs to introduce a double-spend for this horror to work.
asciilifeform: trb as it exists , permits a new tx having same hash as old, so long as old one was spent.
asciilifeform: there are no doublespends involved, just a massive bomb
asciilifeform: mircea_popescu: revisiting the boojum: block 500,000 has coinbase B. it was spent, many cities are built on the outputs, time passes, world forgets. yeas later, dr. evil mines a block ~600,000~ , now again having B. ( he does not need to know any keys for this, can just copy the tx. ) then he sets his minetron to start again from 599,999. succeeds in orphaning block 600,000 . reorg fires. B now gets removed from the index db ! and a
