Published on: 2021-10-03T09:53:00+00:00
In a recent email exchange, Tamas Blummer and Olaoluwa Osuntokun discussed the advantages and disadvantages of various Bitcoin block filters. Blummer suggested that moving to a spent outpoint + output script filter would be more secure and allow light clients to perform further probabilistic checks. However, Osuntokun believes it is too late to change the current deployment of the BIPs and instead suggests adding new filter types in the future.Jim Posen also adds to the discussion, proposing three possibilities for improving client protocol given the limitations of the current filter system. Option two, which involves clients tracking multiple possible filter header chains and considering the union of their matches, is favored by Posen due to its simplicity and support from the BIP 157 P2P protocol.Tamas Blummer has suggested a change to BIP158, which would allow for a decision on which filter chain is correct at lower bandwidth usage. He proposes having a basic filter that contains exactly the spent outpoints and the scriptPubKey of each output aside from all OP_RETURN output scripts for each transaction in a block. The client could then download the entire filter of the block and check it entirely against the contents of the same block. If there is a divergence at a checkpoint, the client would request the filter headers between the last matching and first divergent checkpoint to figure out which block's filter is the first that does not match previous assumptions. The client would then download the corresponding block, check that its header fits the PoW secured best header chain, re-calculate merkle root of its transaction list to know that it is complete and query the filter to see if every output script of every transaction is contained in there. If not, the server is lying, and the case is closed, and the server disconnected.In an email exchange between Tamas Blummer and Laolu Osuntokun, Tamas argued that the current design choice of filters limits light clients from proving filter correctness. He suggested a change to BIP158 to use spent outpoints and output scripts instead of input and output scripts, which would allow for filter correctness to be proven by downloading only the block in question. The advantages of this approach include a simpler interrogation process for filter servers and the ability for clients to decide on the availability of spent coins without maintaining the UTXO set. Jim Posen suggested three possibilities to address this issue, including introducing a new P2P message to retrieve all prev-outputs for a given block, tracking multiple possible filter header chains, or committing filters into the chain via witness reserved value or coinbase OP_RETURN. However, option 2 was favored as it requires the smallest number of changes and is supported by the BIP 157 P2P protocol as currently written.In a Bitcoin development thread, Jim Posen proposed a solution to prevent "input script malleability" and restrict what an attacker can do. This involves introducing a new P2P message to retrieve all prev-outputs for a given block, and verifying the scripts against the block by executing them. However, Olaoluwa Osuntokun stated that it is too late in the current deployment of the BIPs to change things around yet again. Instead, he suggests that the BIP already has measures in place for adding new filter types in the future, which may be worthwhile additions. Matt expressed confusion regarding this proposal and its potential effectiveness.A potential change to Bitcoin Improvement Proposal (BIP) 157/158 has been discussed on the Bitcoin-dev mailing list. Tamas Blummer suggests that a filter collecting spent output and output scripts would be more useful than the current design, as it allows for a decision on filter correctness by knowing the block only. This filter is just as useful for wallets as one on spent script since they naturally scan the blockchain forward and learn about their coins by the output script before they need to check spends of those outpoints.Blummer's proposal involves implementing an interrogation by downloading blocks at checkpoints since it is much simpler than following multiple possible filter paths. A spent outpoint filter allows for deciding on coin availability based on immutable store without the updated and eventually rolled back UTXO store. False positives can be sorted out with a block download.On the other hand, Jim Posen suggested three possibilities in this regard. The first involves introducing a new P2P message to retrieve all prev-outputs for a given block and verifying the scripts against the block by executing them. The second includes clients tracking multiple possible filter header chains and considering the union of their matches. If any filter received for a particular block header matches, the client downloads the block.
Updated on: 2023-08-02T00:28:46.332040+00:00