Topic: Transactions are reorg-resistant, so they can move between chains (Read 64 times)

Recently, I noticed quite interesting attack: the history can be discarded in a very unusual way. To begin with, we can notice, that each transaction can be included in a block number N, or at a time X (according to the locktime, or to the block number in the coinbase transaction), "or later". This "or later" property is a base for the attack.

To notice, how exactly that kind of attack can be mounted, we can try to import mainnet transactions into another test network, like testnet3, signet, or even regtest. To import a coinbase transaction, it is needed to reach the block number N, and the proper coinbase amount. Which means, if our test network has 21 million coins limit, then every transaction can be successfully imported.

For example, if we have a block N, where the coinbase amount is X, we can include other transactions, paying high enough fees, and then the coinbase amount will match. And then, if we have any other, non-coinbase transaction, then we only need to provide valid UTXOs, and then we can include this transaction into our block, even if our network is completely different, but compatible.

So, where is "the attack"? Well, each and every transaction, can be traced back to the coinbase transaction. And here the whole chain of dependencies stops, because then, that particular coinbase transaction, can be included without matching signatures. All inputs are ignored, which means, we don't have to dig deeper, and remember the past, to move this particular coinbase transaction from one network to another.

Also, all coins can be eventually turned into fees, just to forget the past. Which means, according to the consensus rules, we don't have to trace things back further, than to the coinbase transaction. Because that particular thing, can be moved from one chain, to another, without any signatures. The only protection is Proof of Work.

So, how to solve it, and more importantly: should we try? Well, the simplest solution to fix that loophole, is to include a commitment to the previous block hash, in the input of the coinbase transaction. But here is the thing: instead of repeating the hash of the block, people decided to include just the number of the current block, to preserve things, as they were, and to leave this particular case uncovered.

So, why this thing should not be fixed? Well, because then, if Initial Blockchain Download will be too complicated in the future, and if we will want to prune the history in a way, that would be consensus-compatible, then importing coinbase transactions to the new chain, is one of the possible ways to do that.

For example: imagine that all coins will be mined, and we will know exactly, how many spendable UTXOs we have. Then, it could be possible to replace the history with that trick:

1) mine all coins into OP_TRUE (or any other spendable script)
2) if needed: accumulate smaller coins into bigger ones with OP_TRUE (or any other spendable script)
3) send some of those coins as fees
4) include the last N coinbase transactions
5) include the rest of the history, without any modifications

Which means, that it is possible to end up with the compatible chain, that will not contain the full history. Of course, that chain would have different block headers, but what was the most surprising thing for me, was that it is never enforced in any transaction. Which means, that the history of block headers is never signed, and all transactions, back to the Genesis Block, can be potentially migrated from one chain to another, but some of them could be removed, and the chain of signatures would remain unaffected (because coinbase transactions are unsigned, so this is the point, where the chain of signatures is broken: it cannot go further, than to the nearest coinbase transaction).