Understanding SPV, pruning and its downsides, as well

Question

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.

Answer 1

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.

Answer 2

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.