Improving SPV Security With POW Fraud Proofs
Bitcoin full nodes require increasing computer resources that are not available to most of the public, therefore most users tend to use SPV. Simplified Payment Verification is a way for users to check the validity of a block without downloading the whole blockchain, only needing a copy of the block headers of the longest chain.
This schema makes SPV clients vulnerable to forks as it is secure under the assumption that the longest chain is valid and as attacks like Segwit2x have shown and this is not always a safe assumption. A new schema has been proposed on the Bitcoin-dev mailing list that allows invalid blocks to be rejected as long as there are enough honest miners to create a block within a reasonable time frame. The new schema doesn’t fully protect clients against dishonest miners but is an improvement over the current SPV.
The idea is if there is a fork on block N, nodes will disagree on the validity of block N+1, as such an SPV could download this block and check its validity itself, without relying on a full node that could be deceptive.
The idea of downloading a block and checking its validity without downloading the UTXO set at the previous block is currently impossible but with the introduction of UTXO set commitments this will soon change, it will allow the SPV client to check if block N+1 is valid by verifying wether its inputs exist in the UTXO set that was committed to in block N, given reasonable time a valid block will appear and the client will reject its current invalid chain and revert back to the older valid chain.
This way could introduce a new attack vector, as minority miners can make multiple 1-block chain splits forcing SPV clients to download and validate several blocks, but this was counter argued that in case of a malicious split in the chain, it is better to turn SPV clients into full nodes by fully validating blocks themselves than allowing them to connect to a disrupted network.
This idea is fairly interesting with much discussion on the Bitcoin-dev mailing list, you can check out the full discussion here.
Support us and the authors of this article by donating to the following address:38DnHXL85GgqdDmEn52RSn7cKV6WnHDsiL