September has been a quiet month for Bitcoin, there was the honey badger conference and all the talks but there has also been some technical advancements in the background, enabled by the Eltoo proof of concept created by Richard Meyers and recent work on utreexo by Tadge Dryja.
Today we’re covering technical discussions that were done on the bitcoin-dev mailing list for the past month, have a good read!
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.
We covered recently the Leaf-Node weakness and the different proposals that were discussed to address it.
Sergio Demian Lerner, from the RSK team and one of the participants in the discussion, went on presenting his idea for a new fix on his blog.
Recently a fix to the Bitcoin Merkle tree design weakness in the RSK’s bridge was built by making invalid SPV proofs whose internal hashes are valid Bitcoin transaction. While this solves the problem, it is by no means a “clean” solution: it creates false-negative cases (with very low probability) and it reduces verification efficiency.
64 byte transaction, as inner nodes of the merkle tree are constructed
by concatenation of two 32 byte SHA256'd hashes.Matt Corallo via Bitcoin-dev:
BIP 158 currently includes the following in the “basic” filter: 1) txids, 2) output scripts, 3) input prevouts.
I believe (1) could be skipped entirely - there is almost no reason why you’d not be able to filter for, eg, the set of output scripts in a transaction you know about and (2) and (3) may want to be split out - many wallets may wish to just find transactions paying to them, as transactions spending from their outputs should generally be things they’ve created.
BIP 158 is a protocol that extends BIP 157. It is a structure of “compact filters on block data” that replaces bloom filters. The purpose of such a system is to enable users who run light Bitcoin clients to verify transactions dealing specifically with their wallets. The issues at hand are juggling efficiency with security (ie. verifying honest nodes and detecting dishonest nodes).