Would moving a transaction from an old block to a new one allow more pruning?

Question

At Pruning the branches in Merkle Tree Nick ODell writes "A leaf (transaction) can be pruned when all of its outputs have been spent." So I was thinking that if a transaction is one of the last few in a block, a miner can copy the transaction into the new block being mined. That way the miner (and the rest of the network) no longer needs that block for validation, and it can be release into the ether.

Nick also wrote that Bitcoin core won't prune that way anyway because it operates "on the assumption that you download and validate all blocks." I am exploring the reasons for this to see if they can be addressed without keeping everything.

The idea behind downloading the entire blockchain before starting pruning mode is that you want to make sure what you start with is valid. The only known way to do that is to get the whole thing. Or is it? It seems that the ubiquity of the blockchain itself is matched by the ubiquity of the valid UTXO set, so if you get a valid UTXO set and it matches what every other node says, you're good to go. Except for Sybil attacks, right? Would such a successful Sybil attack also allow the blockchain itself to be faked?

One difficulty with my move-a-transaction approach is that when a new node is downloading the blockchain (however much of it is still needed) it will want to verify each block, and if block X is missing, then all the blocks that contain inputs that were created in block X can't be validated, if that means validating that the transactions in it are valid. However, the blockheader itself can still be validated. Block X's header can't be validated because it's contents are missing. But isn't the fact that the hash from block X is required in block X+1 enough to trust that block X was valid, and that, therefore, so are blocks X+1, X+2, X+3, etc., all the way up to and including whatever block-being-validated contains a transaction that uses an output (presumably) created in block X?

When a transaction finally shows up that does spend an unspent output from the moved transaction, it won't be possible to validate it because block X is missing. However, if the index that identifies which block holds which transaction were updated by the miner who moves the transaction, then this is simple to solve.

Would that index-update have to address all the immediate-child transactions of the moved transactions as well so that existing, previously valid transactions could still be validated by finding the source transaction in the newly mined block? I don't think it's necessary to re-validate transactions that are in blocks with validated headers, is it?

Answer 1

This seems a lot of effort for absolutely no benefit.

In the Bitcoin pruning model you discard ALL those old blocks anyway, and JUST keep the utxo set. It doesn't matter whether a utxo is in an old block or a new block, you're still keeping it in the utxoset. Any blocks you keep around is merely for convenience and to assist other nodes that request those blocks.

Answer 2

The simple answer is YES, but there are better solutions. While it allows all transactions to be represented in more recent blocks, the presence of a transaction in a very old block is NOT what prevents the kind of pruning that I envisioned. To make the earliest blocks unnecessary for validating the history of Bitcoin only requires proof that any UTXOs in them actually exist, and that they have not yet been spent. A current UTXO Set would accomplish that, but it has to be proven. Jonas Schnelli suggested something very similar in February.