Published on: 2019-04-21T09:13:00+00:00
The discussion between Ruben Somsen and ZmnSCPxj revolves around the possibility of enabling light clients to verify a single block in isolation. Ruben suggests options like UTXO set commitments, BIP157/158 commitments, or BIP141 fraud proof commitments. While BIP157 can function without commitments, UTXO sets can only be validated by running the entire blockchain. The issue of data unavailability arises when peers allow hearing of all chains while denying proof of the invalidity of some UTXO.Ruben suggests using BIP157/158 filters that contain UTXO spends and are committed to on-chain to resolve this issue. However, ZmnSCPxj argues that validating every input in a block through the filter of every past block may be computationally expensive. Ruben also points out that storing and transmitting UTXO set commitments, utreexo commitments, or BIP158 filter digests over the network needs to be addressed. Storing these commitments in fullnodes at each block may increase resource usage.The current understanding of options for enabling light clients to verify a single block in isolation is UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments.The discussion also delves into the validity of UTXO sets and fraud proofs in blockchain technology. Trusting every peer or omitting the proof is not acceptable as it requires one honest peer. Peers can be set up to allow hearing of all chains while denying proof of invalidity of some UTXO, leading to the issue of data unavailability.BIP157 manages to function without commitments, but UTXO sets require downloading the entire blockchain for validation. Ruben suggests combining BIP157/158 with UTXO set commitments, but ZmnSCPxj raises concerns about the computational expense of running every input in a block through the filter of every past block. The need to store and transmit commitments over the network is also highlighted, with potential resource usage increase in fullnodes if stored in coinbase.The conversation explores the possibility of using UTXO sets without identifying who validates them or making it expensive to lie. Ruben proposes committing to the location of UTXOs being spent by miners, allowing full nodes to prove invalidity to SPV clients. However, ZmnSCPxj argues that validating a block requires knowing the validity of every UTXO spent by transactions in that block, which may require downloading all blocks between the current block being verified and the block containing the UTXO to be validated.The email thread also discusses the security concerns related to Simplified Payment Verification (SPV) in Bitcoin. It is noted that a minority miner with significant mining power can disrupt SPV clients by creating multiple 1-block chainsplits and forcing them to download every block. Ethan Heilman suggests that SPV clients should download and validate the "longest chain" up to more than one block greater than the height of the losing chain to prevent such attacks. However, ZmnSCPxj highlights the potential loopholes and new attack possibilities that every rule imposes.The discussion concludes with the reminder to exercise caution when implementing rules to prevent attacks on the Bitcoin network.In summary, the email conversation covers various aspects of enabling light clients to verify a single block in isolation, including options like UTXO set commitments, BIP157/158 commitments, and BIP141 fraud proof commitments. The challenges of data unavailability and computational expense are discussed, along with the need to store and transmit commitments over the network. The vulnerability of SPV clients and the potential for disruption by a minority miner are also explored, emphasizing the importance of careful consideration when implementing rules to prevent attacks.Ruben Somsen proposed an improvement to Simplified-Payment-Verification (SPV) mechanism which is secure under the assumption that the chain with the most Proof-of-Work (PoW) is valid. He suggested that invalid blocks will be rejected as long as there are enough honest miners to create a block within a reasonable time frame. This improves SPV clients against dishonest miners and is compatible with the privacy improvements of BIP157.The idea is that a fork is an indication of potential misbehavior, and its block header can serve as a PoW fraud proof. Conversely, the lack of a fork is an indication that a block is valid. If a fork is created from a block at height N, this means a subset of miners may disagree on the validity of block N+1. If SPV clients download and verify this block, they can judge for themselves whether or not the chain should be rejected.Bitcoin currently cannot verify the validity of block N+1 without knowing the UTXO set at block N, even if you are willing to assume that block N (and everything before it) is valid.
Updated on: 2023-08-02T00:44:08.482399+00:00