Feed for tag: spv
Recap for September 2019

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!

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.

A summary of the HoneyBadger conference
The Baltic Honeybadger conference is the first major event in Latvia dedicated to Bitcoin and the technologies built around it. This year’s second edition panelists included major Bitcoin developers like Brian bishop, Matt Corallo and Eric Voskuil, Cryptography specialists like Adam Back and Peter Todd, CEOs like Elizabeth Stark and Eric Lombrozo and many others. Here’s a summary of the two-day panels …
A Change to the MERKLEBLOCK command to protect from Leaf-Node weakness

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.

CVE-2017-12842: Trusted Merkle Tree Depth for Safe Tx Inclusion Proofs Without a Soft Fork
Recently a weakness in the merkle tree algorithm of Bitcoin, called Leaf-Node weakness was discussed during a responsible discolsure. It’s been known for a while that the Merkle tree algorithm fails to distinguish between inner nodes and a 64 byte transaction, as inner nodes of the merkle tree are constructed by concatenation of two 32 byte SHA256'd hashes.
BIP-158: Flexibility and Filter Size for Light Bitcoin Clients

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).

BIP 157 & 158: Block Filtering
A new BIP was suggested to improve the efficiency of light client protocols in Bitcoin, instead of the current BIP 37’s light client protocol that has flaws such as allowing denial-of-service attack vectors on full nodes, the new protocol allows light clients to obtain compact probabilistic filters of block content from full nodes and only download a block if the filter matches the relevant data.
Why Not Witnessless Nodes
Kalle Rosenbaum initiated a discussion on the bitcoin-dev mailing list regarding the feasibility of witnessless nodes. Bitcoin Core v0.14.0 introduced a new feature called assumevalid which allows a node to skip verification of all the blocks. Why not take it a step further? Let’s begin by reviewing what happens when a new nodes comes online: