<p>You are right, completely discarding transactions whose outputs have been spent would not work. New full nodes would still need all data to be able to process the blockchain and build the current UTXO set. So, the Merkle tree pruning idea doesn't seem beneficial and maintaining the UTXO set separately in combination with pruning old blocks is more efficient.</p>
<p>Fraud Proofs are another thing that never has been implemented. They were meant as a way for full nodes to tell SPV clients when a blockchain tip is invalid. They are related in so far, that they suffer from the same issue: there is no good way how to prove the non-existence of a UTXO, yet. If someone just doublespent a UTXO it would be easy to point out where the UTXO was spent already, but if a block contains a transaction spending a UTXO that never was created, it's non-trivial to prove that—a full node can just tell because they calculated the complete UTXO set themselves, which in turn is hard to prove as well. It would get much easier, if we did commit to the UTXO set somewhere, but even then, the smallest proof might consist of a proof of absence in the last UTXO set commitment (which with a canonical ordered UTXO set could be as simple as the two neighboring UTXOs between which the UTXO should have appeared), and all the blocks since that commitment. Fraud proofs might be possible if we committed to the UTXO set in every block.</p>
<blockquote>
<p>Furthermore, I've heard that the Mimblewimble protocol enables secure blockchain pruning. I'm also curious how Mimblewimble could achieve this, and whether similar goal could be eventually achieved in Bitcoin?</p>
</blockquote>
<p>Mimblewimble transactions can be <a href="https://www.mwc.mw/what-is-mimblewimble" rel="nofollow noreferrer">non-interactively aggregated</a>. Any outputs that were spent by subsequent inputs cancel out at that point (which is referred to as <em>transaction cut-through</em>). The only data that cannot be pruned are the <em>kernels</em> which are a combination of signature and proof that no new funds were created. In effect, the whole Mimblewimble blockchain is a single large coinjoin transaction unless you observed/recorded the original transaction before it was aggregated. The approach cannot be ported to Bitcoin without vast redesign of the transaction format and consensus rules. In this context, it may be interesting to glance at Litecoin's Mimblewimble extension block protocol update.</p>

CC BY-SA 4.0
2022-04-04T14:41:57.363Z
Regards "how to prove the non-existence of a UTXO", AFAIK maybe it could be achieved by adding a new consensus rule, which requires each transaction input must explicitly point to where the coins came from (block height etc). If it's just already spent rather than never existed, then maybe a node can maintain a index for S(pent)TxO locally to handle this.
Chris Chen
CC BY-SA 4.0
2022-04-04T15:01:52.710Z
AFAIK what really blocks (even kills) fraud proofs is the difficulty (maybe impossibility?) to prove data unavailability. IIRC Luke Dashjr once illustrated an example that a block has an inconsistent Merkle tree which contains "hash" that is not a hash (of subtree or leaf node/tx) at all, but just random meaningless gibberish. Ironically even the malicious miner himself who created such block cannot prove it's "invalidity", because the possiblity that there might be a valid preimage cannot be ruled out. Full node will eventually ignore it, while SPV can do nothing execpt becoming a full node.
Chris Chen
CC BY-SA 4.0
2022-03-15T16:28:32.357Z
2022-03-15T16:28:32.357Z
Murch
<p>From what I understand, a full node will download everything, verify everything first. Then only the pruning starts. Thus, the issue of inconsistent pruning does not arise. As off now, there is no common consensus on the UTXO sets. For example, up to block 500,000, the UTXO set is &quot;XXXX&quot;.  Just download &quot;XXXX&quot;,it should be fine. I believe we will have this feature in the future. As off now, fullnode have to download everything, verify and then only prune.</p>

CC BY-SA 4.0
2020-06-23T03:01:23.250Z
2020-06-23T03:01:23.250Z
Cisco Mmu
<p>When I was reading <a href="https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3" rel="nofollow noreferrer">bitcoin-paper-errata-and-details.md</a> written by David A. Harding, I realized that there's probably a common misunderstanding or over-simplification about Merkle tree pruning. <a href="https://bitcoin.stackexchange.com/a/36101/77103">What Nick ODell had said</a> might be a live example:</p>
<blockquote>
<ul>
<li>A leaf (transaction) can be pruned when all of its outputs have been spent.</li>
</ul>
</blockquote>
<p>This once seemed to be true for me, until I read <a href="https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#7-reclaiming-disk-space" rel="nofollow noreferrer">what David had written</a>:</p>
<blockquote>
<p>there is currently no way in Bitcoin to prove that a transaction has not been spent</p>
</blockquote>
<p>I'm not sure whether I have grasped it, so firstly I made a diagram to illustrate (part of) my understanding to this problem:</p>
<p><a href="https://i.sstatic.net/JYNwJ.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/JYNwJ.png" alt="incensistent-pruning" /></a></p>
<p>Still, I don't think merely this problem can kill the whole idea of Merkle tree pruning yet, I think it just means that &quot;the reclaimable disk capacity is much lower than expectation&quot;. In other words, if I'm not mistaken, Nick ODell's claim could be &quot;corrected&quot; like:</p>
<blockquote>
<ul>
<li>A leaf (transaction) can be pruned when all of its outputs have been spent, <strong>and all of its previous transactions have been pruned.</strong></li>
</ul>
</blockquote>
<p>However, I then think that, even if the &quot;corrected&quot; claim is taken into consideration, the idea of Merkle tree pruning still doesn't seem to be feasible/useful:</p>
<ol>
<li><p>Even if the problem mentioned above can be avoided by honest nodes, a malicious node can still deceive the new full node by hiding/picking some merkle branches. <strong>A malicious node can lie about the actual ownership of coins (spent/unspent state) without breaking the Merkle tree structure at all.</strong> In other words, a new full node joining the network still needs to download &amp; verify everything, otherwise, it could be deceived by a malicious node.</p>
</li>
<li><p>If a full node needs to enable pruning to reduce disk space requirement <strong>for itself</strong>, directly reading/modifying the blockchain files seems to be <strong>much less efficient</strong> than the current implementation that the UTXO set is completely separated from the blockchain storage, so that a full node (no matter it's pruning or not) only needs to query and update the UTXO set database during the downloading &amp; validation process. The blockchain itself doesn't need to be touched once again for validation purposes at all, which is the reason why the old blocks can be simply deleted when &quot;pruning&quot; (not Merkle tree pruning) is enabled.</p>
</li>
</ol>
<p>However, I'm still not sure about this conclusion. Is this related to the idea of fraud proofs, in the sense that as long as there's still at least one honest full node, the new node would be able to spot which piece of data is the correct one? What if the UTXO set is also committed to the blockchain? What if some more commitments like the block height of previous transaction are also added to the blockchain?</p>
<p>Furthermore, I've heard that the Mimblewimble protocol enables secure blockchain pruning. I'm also curious how Mimblewimble could achieve this, and whether similar goal could be eventually achieved in Bitcoin?</p>

<merkle-tree><pruning><whitepaper><fraudproofs>
Is Merkle tree pruning described in the whitepaper feasible/useful? If not, would there be any alternative?
Chris Chen
# Is Merkle tree pruning described in the whitepaper feasible/useful? If not, would there be any alternative?

(Asked by: username_0 on 2020-06-22)

When I was reading [bitcoin-paper-errata-and-details.md](https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3) written by David A. Harding, I realized that there's probably a common misunderstanding or over-simplification about Merkle tree pruning. [What Nick ODell had said](https://bitcoin.stackexchange.com/a/36101/77103) might be a live example:

> * A leaf (transaction) can be pruned when all of its outputs have been spent.

This once seemed to be true for me, until I read [what David had written](https://gist.github.com/harding/dabea3d83c695e6b937bf090eddf2bb3#7-reclaiming-disk-space):

> there is currently no way in Bitcoin to prove that a transaction has not been spent

I'm not sure whether I have grasped it, so firstly I made a diagram to illustrate (part of) my understanding to this problem:

[![incensistent-pruning](https://i.sstatic.net/JYNwJ.png)](https://i.sstatic.net/JYNwJ.png)

Still, I don't think merely this problem can kill the whole idea of Merkle tree pruning yet, I think it just means that "the reclaimable disk capacity is much lower than expectation". In other words, if I'm not mistaken, Nick ODell's claim could be "corrected" like:

> * A leaf (transaction) can be pruned when all of its outputs have been spent, **and all of its previous transactions have been pruned.**

However, I then think that, even if the "corrected" claim is taken into consideration, the idea of Merkle tree pruning still doesn't seem to be feasible/useful:

1. Even if the problem mentioned above can be avoided by honest nodes, a malicious node can still deceive the new full node by hiding/picking some merkle branches. **A malicious node can lie about the actual ownership of coins (spent/unspent state) without breaking the Merkle tree structure at all.** In other words, a new full node joining the network still needs to download & verify everything, otherwise, it could be deceived by a malicious node.
2. If a full node needs to enable pruning to reduce disk space requirement **for itself**, directly reading/modifying the blockchain files seems to be **much less efficient** than the current implementation that the UTXO set is completely separated from the blockchain storage, so that a full node (no matter it's pruning or not) only needs to query and update the UTXO set database during the downloading & validation process. The blockchain itself doesn't need to be touched once again for validation purposes at all, which is the reason why the old blocks can be simply deleted when "pruning" (not Merkle tree pruning) is enabled.

However, I'm still not sure about this conclusion. Is this related to the idea of fraud proofs, in the sense that as long as there's still at least one honest full node, the new node would be able to spot which piece of data is the correct one? What if the UTXO set is also committed to the blockchain? What if some more commitments like the block height of previous transaction are also added to the blockchain?

Furthermore, I've heard that the Mimblewimble protocol enables secure blockchain pruning. I'm also curious how Mimblewimble could achieve this, and whether similar goal could be eventually achieved in Bitcoin?

**Tags:** merkle-tree, pruning, whitepaper, fraudproofs


---

## 2 answers

### Answer by username_1 on 2022-03-15. Score: 1

You are right, completely discarding transactions whose outputs have been spent would not work. New full nodes would still need all data to be able to process the blockchain and build the current UTXO set. So, the Merkle tree pruning idea doesn't seem beneficial and maintaining the UTXO set separately in combination with pruning old blocks is more efficient.

Fraud Proofs are another thing that never has been implemented. They were meant as a way for full nodes to tell SPV clients when a blockchain tip is invalid. They are related in so far, that they suffer from the same issue: there is no good way how to prove the non-existence of a UTXO, yet. If someone just doublespent a UTXO it would be easy to point out where the UTXO was spent already, but if a block contains a transaction spending a UTXO that never was created, it's non-trivial to prove that—a full node can just tell because they calculated the complete UTXO set themselves, which in turn is hard to prove as well. It would get much easier, if we did commit to the UTXO set somewhere, but even then, the smallest proof might consist of a proof of absence in the last UTXO set commitment (which with a canonical ordered UTXO set could be as simple as the two neighboring UTXOs between which the UTXO should have appeared), and all the blocks since that commitment. Fraud proofs might be possible if we committed to the UTXO set in every block.

> Furthermore, I've heard that the Mimblewimble protocol enables secure blockchain pruning. I'm also curious how Mimblewimble could achieve this, and whether similar goal could be eventually achieved in Bitcoin?

Mimblewimble transactions can be [non-interactively aggregated](https://www.mwc.mw/what-is-mimblewimble). Any outputs that were spent by subsequent inputs cancel out at that point (which is referred to as *transaction cut-through*). The only data that cannot be pruned are the *kernels* which are a combination of signature and proof that no new funds were created. In effect, the whole Mimblewimble blockchain is a single large coinjoin transaction unless you observed/recorded the original transaction before it was aggregated. The approach cannot be ported to Bitcoin without vast redesign of the transaction format and consensus rules. In this context, it may be interesting to glance at Litecoin's Mimblewimble extension block protocol update.

> **Comments:**
> **username_0**: Regards "how to prove the non-existence of a UTXO", AFAIK maybe it could be achieved by adding a new consensus rule, which requires each transaction input must explicitly point to where the coins came from (block height etc). If it's just already spent rather than never existed, then maybe a node can maintain a index for S(pent)TxO locally to handle this.  
> **username_0**: AFAIK what really blocks (even kills) fraud proofs is the difficulty (maybe impossibility?) to prove data unavailability. IIRC Luke Dashjr once illustrated an example that a block has an inconsistent Merkle tree which contains "hash" that is not a hash (of subtree or leaf node/tx) at all, but just random meaningless gibberish. Ironically even the malicious miner himself who created such block cannot prove it's "invalidity", because the possiblity that there might be a valid preimage cannot be ruled out. Full node will eventually ignore it, while SPV can do nothing execpt becoming a full node.  

---

### Answer by username_2 on 2020-06-23. Score: 0

From what I understand, a full node will download everything, verify everything first. Then only the pruning starts. Thus, the issue of inconsistent pruning does not arise. As off now, there is no common consensus on the UTXO sets. For example, up to block 500,000, the UTXO set is "XXXX". Just download "XXXX",it should be fine. I believe we will have this feature in the future. As off now, fullnode have to download everything, verify and then only prune.


---

