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?