<p>This seems a lot of effort for absolutely no benefit.</p>

<p>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.</p>

CC BY-SA 3.0
2016-05-24T22:40:51.023Z
The largest portion of bitcoiners who will contribute to the network is nearly always going to be far larger than the number who have all the data they need to help the newcomers. Those newcomers are facing ever larger downloads to get started. Pruning doesn't fix that. Pruning only fixed the persistent storage problem, which is relatively insignificant to the startup cost. My aim is to make participation easier to begin.
Dave Scotese
CC BY-SA 3.0
2016-05-25T02:35:07.727Z
Much simpler solution: commit a proof of the utxoset in the block header every N blocks, and nodes make that utxoset available for download. The chain can be verified on block headers alone, and the utxoset can be verified based on the commitment in the header.
Riaan Swart
CC BY-SA 3.0
2016-05-26T16:09:02.880Z
If block 414000 is the first one with that UTXO commitment then I'm guessing that at block 414550, it's safe to download less than the entire blockchain.  The newcomer determines whether or not the UTXO set they download (from source 1) is correct by waiting N blocks to make sure that the next commitment (which they get from Source 2) includes the changes those N blocks made.  If it fails that check, they start all over again, but they can't tell which of the two sources is the problem.  I guess that easily fixed by using multiple sources.
Dave Scotese
CC BY-SA 3.0
2016-05-26T16:17:38.797Z
So headers would be downloaded from multiple sources to be cross-checked, and after N blocks the newcomer can verify that the transactions in them produce the correct new UTXO commitment.  I'm trying to identify ways to exploit the lack of validation of all the blocks before the last 550 because I like the idea, but I worry that it is giving up too much independent validation.
Dave Scotese
CC BY-SA 3.0
2016-05-22T21:41:32.413Z
2016-05-22T21:41:32.413Z
Riaan Swart
<p>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. <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html" rel="nofollow">Jonas Schnelli suggested something very similar in February.</a></p>

CC BY-SA 3.0
2016-06-14T23:33:28.247Z
2016-06-16T17:36:23.147Z
2016-06-16T17:36:23.147Z
Dave Scotese
<p>At <a href="https://bitcoin.stackexchange.com/questions/36100/pruning-the-branches-in-merkle-tree">Pruning the branches in Merkle Tree</a> 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.</p>

<p>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 <a href="https://bitcoin.stackexchange.com/questions/45911/can-bitcoin-node-startup-be-secure-without-validating-the-entire-blockchain">exploring the reasons for this</a> to see if they can be addressed without keeping everything.</p>

<p>The idea behind downloading the entire blockchain <em>before</em> 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?</p>

<p>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?</p>

<p>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.</p>

<p>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?</p>

CC BY-SA 3.0
2016-06-13T16:06:12.910Z
This post is convoluted, and based on assumptions that should first be addressed separately, e.g. whether it is necessary to parse the complete blockchain, and reliance on a UTXO set provided by other users. Also, a copied transaction causes the including block to be invalid under current rules. Finally, the UTXO information is sufficient to validate an input, so you don't need "block X". That's why pruning as implemented works, and pruning as described never got followed-up on. In the result, I don't find the question as it is useful and suggest that it should be reworked and condensed.
Murch
CC BY-SA 3.0
2016-06-15T08:07:53.083Z
I would like to thank you for responding to my suggestion by actually asking more questions and investigating the points. So often, I've been insulted or attacked for such feedback that what may seem as natural is a pleasant surprise.
Murch
<transactions><blockchain><pruning><validation>
Would moving a transaction from an old block to a new one allow more pruning?
Dave Scotese
# Would moving a transaction from an old block to a new one allow more pruning?

(Asked by: username_0 on 2016-05-22)

At [Pruning the branches in Merkle Tree](https://bitcoin.stackexchange.com/questions/36100/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](https://bitcoin.stackexchange.com/questions/45911/can-bitcoin-node-startup-be-secure-without-validating-the-entire-blockchain) 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?

**Tags:** transactions, blockchain, pruning, validation

> **Comments:**
> **username_1**: This post is convoluted, and based on assumptions that should first be addressed separately, e.g. whether it is necessary to parse the complete blockchain, and reliance on a UTXO set provided by other users. Also, a copied transaction causes the including block to be invalid under current rules. Finally, the UTXO information is sufficient to validate an input, so you don't need "block X". That's why pruning as implemented works, and pruning as described never got followed-up on. In the result, I don't find the question as it is useful and suggest that it should be reworked and condensed.  
> **username_1**: I would like to thank you for responding to my suggestion by actually asking more questions and investigating the points. So often, I've been insulted or attacked for such feedback that what may seem as natural is a pleasant surprise.  

---

## 2 answers

### Answer by username_2 on 2016-05-22. Score: 4

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.

> **Comments:**
> **username_0**: The largest portion of bitcoiners who will contribute to the network is nearly always going to be far larger than the number who have all the data they need to help the newcomers. Those newcomers are facing ever larger downloads to get started. Pruning doesn't fix that. Pruning only fixed the persistent storage problem, which is relatively insignificant to the startup cost. My aim is to make participation easier to begin.  
> **username_2**: Much simpler solution: commit a proof of the utxoset in the block header every N blocks, and nodes make that utxoset available for download. The chain can be verified on block headers alone, and the utxoset can be verified based on the commitment in the header.  
> **username_0**: If block 414000 is the first one with that UTXO commitment then I'm guessing that at block 414550, it's safe to download less than the entire blockchain.  The newcomer determines whether or not the UTXO set they download (from source 1) is correct by waiting N blocks to make sure that the next commitment (which they get from Source 2) includes the changes those N blocks made.  If it fails that check, they start all over again, but they can't tell which of the two sources is the problem.  I guess that easily fixed by using multiple sources.  
> **username_0**: So headers would be downloaded from multiple sources to be cross-checked, and after N blocks the newcomer can verify that the transactions in them produce the correct new UTXO commitment.  I'm trying to identify ways to exploit the lack of validation of all the blocks before the last 550 because I like the idea, but I worry that it is giving up too much independent validation.  

---

### Answer by username_0 on 2016-06-14. Score: 1

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.](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html)


---

