<blockquote>
  <p>So, as I understand, an SPV client just receives the latest merkle root of the latest block and verify if a transaction is in it. It then see that very much hashpower was wasted on that block, and then assumes that it should be a valid block. Am I right?</p>
</blockquote>

<p>No. A SPV client submits a bloom filter to a full node providing SPV services. Each time a block header is sent to you, a full node will check against said bloom filter is transactions that you may or may not be interested is in the block. </p>

<p>If yes, then said transactions will be included, including all other transactions required to compute the Merkle Root. Otherwise, you just receive a block header with no transactions whatsoever. For each block header received, your SPV client will check if it contains a proof of work solution that meets the difficulty requirement and if it is linked to the previous block (as usual).</p>

<blockquote>
  <p>In pruning mode, however, the entire blockchain is downloaded, verified, and then pruned. Now, the client just downloads new blocks, verifies them, and prunes them. As I've read, however, in pruning mode, the client maintains the latest x blocks for some reason. Why?</p>
</blockquote>

<p>I assume you are talking in terms of a full node, since SPV nodes do not download the blockchain at all and there's nothing to prune.</p>

<p>The reason why the last N blocks are kept is so that when a re-organisation takes place, it is possible to systematically undo transactions that led to the current UTXO set which is based off an orphaned chain. You then undo to the point where the new succeeding chain begins and apply transactions recorded in the new chain. Without the last N blocks, there's no way to un-wind when chain re-org takes place, then to re-derive the UTXO independently requires a full download of the blockchain.</p>

<blockquote>
  <p>Also, if I have the entire blockchain in pruned mode, that is, a blockchain made of only merkle trees, given a new transaction and its merkle path, I can verify that it's in some block and I know that this block is valid because I validated it before pruning. However, how do I know that this transaction spends an unspent input? Do I need to ask for the merkle path of the referenced transaction and keep doing that?</p>
</blockquote>

<p>I think you are confused here. While operating a full node in prune mode, your node will download every block and perform full validation. Each transaction that gets processed will update the UTXO set that is cached on your node. Therefore, you will know if transactions are spending valid UTXOs or not. </p>

CC BY-SA 3.0
2017-08-03T06:21:34.483Z
So in pruning mode it'll download the entire blockchain, prune all the transactions that were already spent (pruning means deleting or just saving the merkle tree?), keeping just the ones unspent, so it can check the validity of all new transactions, right? So the only difference of pruning mode vs full mode is that pruning won't helo by providing transactions to the network that were already spent, so new nodes would not be able to download the blockchain to verify it, right?
Guerlando OCs
CC BY-SA 3.0
2017-08-03T06:39:49.823Z
No merkle tree is being saved in prune mode. The merkle root hash is stored in the block header and the merkle tree is only useful during validation of a block. Yes, prune mode keeps a set of unspent transaction outputs to verify new incoming transactions. Yes, full nodes running in prune mode wont be able to serve historical blocks to other peers.
rny
CC BY-SA 3.0
2017-08-04T00:02:10.780Z
but is this the only downside of pruning mode?
Guerlando OCs
CC BY-SA 3.0
2017-08-04T00:40:45.617Z
Yes. There's no other downside to pruning mode other than you not being able to serve historical blocks
rny
CC BY-SA 3.0
2017-08-03T04:44:11.087Z
2017-08-03T04:44:11.087Z
rny
<p>bitcoin has an orphaning rate of 0.5% due to competition in mining. Thus, keeping the last N block is a conservative method to prevent extra work as stated in the previous answer.</p>

CC BY-SA 4.0
2020-04-15T08:34:17.247Z
2020-04-15T08:34:17.247Z
Cisco Mmu
<p>First of all, sorry by not asking an objective question, it's because I can't resume this one and I didn't find information even in the "mastering bitcoin" book. The large texts in this question are also to help people get in the context of what I'm asking.</p>

<p>Suppose I run a bitcoin client in pruning mode. As I understand, it'll download the entire blockchain, verify that the transactions are well formed, don't spend unexistent outputs, the signatures match, and the hashes of the block match. After that, it'll erase everything and just store the Merkle Trees of each block. I understand how a Merkle Tree works, it's a structure made of hashes of transaction IDs. Given a transaction and its merkle path, I can verify if the transaction is in the block or not.</p>

<p>If I just accept blocks from the network but did not previously verify the blockchain, I could be fooled to verify that a transaction is in the mined block, but I would not be able to verify if the transaction is well formed, if it spends unspent outputs, etc. So that's why the entire blockchain must be downloaded and verified before. (even though, it's unlikely that someone would waste hashpower to mine a block with an invalid input, but of course if we rely on unlikely, it would open a port for this possibility).</p>

<p><strong>So, as I understand, an SPV client just receives the latest merkle root of the latest block and verify if a transaction is in it. It then see that very much hashpower was wasted on that block, and then assumes that it should be a valid block. Am I right?</strong></p>

<p>In pruning mode, however, the entire blockchain is downloaded, verified, and then pruned. Now, the client just downloads new blocks, verifies them, and prunes them. <strong>As I've read, however, in pruning mode, the client maintains the latest x blocks for some reason. Why?</strong> </p>

<p>Also, if I have the entire blockchain in pruned mode, that is, a blockchain made of only merkle trees, given a new transaction and its merkle path, I can verify that it's in some block and I know that this block is valid because I validated it before pruning. <strong>However, how do I know that this transaction spends an unspent input?</strong> Do I need to ask for the merkle path of the referenced transaction and keep doing that?</p>

<p>In the current model in my head, I don't see how a pruning node could be fooled. <strong>Is the only downside of pruning nodes that they don't help the network very much?</strong> Because they can't provide merkle paths for those who ask, etc. <strong>But if I receive a transaction and I am a pruning client, can I have the same confidence as a full node that I'm not being fooled?</strong></p>

<p>Is there any other disavantage of pruning that I don't know? I'm asking because I'm verfy intersted in this model and I want to run a pruning client. </p>

CC BY-SA 3.0
2017-08-02T05:00:28.657Z
there's no pruning while operating in SPV mode afaik.
rny
CC BY-SA 3.0
2017-08-02T05:21:48.793Z
@renlord yes. In SPV, you just download the block header, see that it has a lot of hashpower in it by examining the hash, and then you get a transaction and see that it's included in the merkle tree, right? No pruning
Guerlando OCs
<bitcoind><merkle-tree><spv><pruning>
Understanding SPV, pruning and its downsides, as well
Guerlando OCs
# Understanding SPV, pruning and its downsides, as well

(Asked by: username_0 on 2017-08-02)

First of all, sorry by not asking an objective question, it's because I can't resume this one and I didn't find information even in the "mastering bitcoin" book. The large texts in this question are also to help people get in the context of what I'm asking.

Suppose I run a bitcoin client in pruning mode. As I understand, it'll download the entire blockchain, verify that the transactions are well formed, don't spend unexistent outputs, the signatures match, and the hashes of the block match. After that, it'll erase everything and just store the Merkle Trees of each block. I understand how a Merkle Tree works, it's a structure made of hashes of transaction IDs. Given a transaction and its merkle path, I can verify if the transaction is in the block or not.

If I just accept blocks from the network but did not previously verify the blockchain, I could be fooled to verify that a transaction is in the mined block, but I would not be able to verify if the transaction is well formed, if it spends unspent outputs, etc. So that's why the entire blockchain must be downloaded and verified before. (even though, it's unlikely that someone would waste hashpower to mine a block with an invalid input, but of course if we rely on unlikely, it would open a port for this possibility).

**So, as I understand, an SPV client just receives the latest merkle root of the latest block and verify if a transaction is in it. It then see that very much hashpower was wasted on that block, and then assumes that it should be a valid block. Am I right?**

In pruning mode, however, the entire blockchain is downloaded, verified, and then pruned. Now, the client just downloads new blocks, verifies them, and prunes them. **As I've read, however, in pruning mode, the client maintains the latest x blocks for some reason. Why?**

Also, if I have the entire blockchain in pruned mode, that is, a blockchain made of only merkle trees, given a new transaction and its merkle path, I can verify that it's in some block and I know that this block is valid because I validated it before pruning. **However, how do I know that this transaction spends an unspent input?** Do I need to ask for the merkle path of the referenced transaction and keep doing that?

In the current model in my head, I don't see how a pruning node could be fooled. **Is the only downside of pruning nodes that they don't help the network very much?** Because they can't provide merkle paths for those who ask, etc. **But if I receive a transaction and I am a pruning client, can I have the same confidence as a full node that I'm not being fooled?**

Is there any other disavantage of pruning that I don't know? I'm asking because I'm verfy intersted in this model and I want to run a pruning client.

**Tags:** bitcoind, merkle-tree, spv, pruning

> **Comments:**
> **username_1**: there's no pruning while operating in SPV mode afaik.  
> **username_0**: @renlord yes. In SPV, you just download the block header, see that it has a lot of hashpower in it by examining the hash, and then you get a transaction and see that it's included in the merkle tree, right? No pruning  

---

## 2 answers

### Answer by username_1 on 2017-08-03. Score: 2 | Accepted answer

> So, as I understand, an SPV client just receives the latest merkle root of the latest block and verify if a transaction is in it. It then see that very much hashpower was wasted on that block, and then assumes that it should be a valid block. Am I right?

No. A SPV client submits a bloom filter to a full node providing SPV services. Each time a block header is sent to you, a full node will check against said bloom filter is transactions that you may or may not be interested is in the block.

If yes, then said transactions will be included, including all other transactions required to compute the Merkle Root. Otherwise, you just receive a block header with no transactions whatsoever. For each block header received, your SPV client will check if it contains a proof of work solution that meets the difficulty requirement and if it is linked to the previous block (as usual).

> In pruning mode, however, the entire blockchain is downloaded, verified, and then pruned. Now, the client just downloads new blocks, verifies them, and prunes them. As I've read, however, in pruning mode, the client maintains the latest x blocks for some reason. Why?

I assume you are talking in terms of a full node, since SPV nodes do not download the blockchain at all and there's nothing to prune.

The reason why the last N blocks are kept is so that when a re-organisation takes place, it is possible to systematically undo transactions that led to the current UTXO set which is based off an orphaned chain. You then undo to the point where the new succeeding chain begins and apply transactions recorded in the new chain. Without the last N blocks, there's no way to un-wind when chain re-org takes place, then to re-derive the UTXO independently requires a full download of the blockchain.

> Also, if I have the entire blockchain in pruned mode, that is, a blockchain made of only merkle trees, given a new transaction and its merkle path, I can verify that it's in some block and I know that this block is valid because I validated it before pruning. However, how do I know that this transaction spends an unspent input? Do I need to ask for the merkle path of the referenced transaction and keep doing that?

I think you are confused here. While operating a full node in prune mode, your node will download every block and perform full validation. Each transaction that gets processed will update the UTXO set that is cached on your node. Therefore, you will know if transactions are spending valid UTXOs or not.

> **Comments:**
> **username_0**: So in pruning mode it'll download the entire blockchain, prune all the transactions that were already spent (pruning means deleting or just saving the merkle tree?), keeping just the ones unspent, so it can check the validity of all new transactions, right? So the only difference of pruning mode vs full mode is that pruning won't helo by providing transactions to the network that were already spent, so new nodes would not be able to download the blockchain to verify it, right?  
> **username_1**: No merkle tree is being saved in prune mode. The merkle root hash is stored in the block header and the merkle tree is only useful during validation of a block. Yes, prune mode keeps a set of unspent transaction outputs to verify new incoming transactions. Yes, full nodes running in prune mode wont be able to serve historical blocks to other peers.  
> **username_0**: but is this the only downside of pruning mode?  
> **username_1**: Yes. There's no other downside to pruning mode other than you not being able to serve historical blocks  

---

### Answer by username_2 on 2020-04-15. Score: 0

bitcoin has an orphaning rate of 0.5% due to competition in mining. Thus, keeping the last N block is a conservative method to prevent extra work as stated in the previous answer.


---

