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!

[core] PoW fraud proofs without a soft fork

Simplified Payment Verification clients are used everywhere because not every one has the capability of running their own full node, they are secure under the assumption that the chain with the most proof of work is the valid one. This assumption is not always safe as demonstrated by attacks like Segwit2x.

An idea was recently proposed on the bitcoin-dev network that improves this assumption. The idea is that a fork is an indication of a potential attack, once a fork is detected an SPV client would download and verify the next block.

This isn’t possible but with the introduction of UTXO set commitments, the next block can be validated by validating the existence of its inputs in the previous block’s UTXO set.

Recent work on utreexo by Tadge Dryja further improved on this by making it possible without a soft fork, instead of downloading the hash commitment inside of the previous block, we’d download the utreexo hash of the previous block from all peers, assuming some peers disagree on what the correct hash is, we’d find the last block with an agreed upon utreexo hash then repeat the same process to verify which peers correctly transitioned their utreexo hash.

This allows SPV clients to gain the ability to eventually reject the chain with the most PoW as long as an honest block is mined, all without a soft-fork!

If you’d like to read more about PoW fraud proofs, please refer to this discussion.

[core] Block Batch Filters for Light Clients

BIP 157 provided an alternative to SPV clients, SPV clients currently work by sending a filter to the full nodes its connected to which tells them the type of transactions the client is interested in. The scheme does not give a lot of privacy to the client because it allows the server to guess the addresses related to the client revealing all kinds of financial data, it is places a lot of trust in the server. This is a trade-off to save bandwidth as BIP 37 SPV clients only need about 3KB of data for blocks they participated in and about 80 bytes for other blocks.

BIP 157 operation is completely in reverse, the server sends the client compressed data of every block then the client checks if its interested in it by using filters, and if it is, the client sends a request to the server to send this block in full, the compression used is pretty efficient as it gets a normal 1.4MB block into about 20KB of compressed data but its still far from the 3KB of data used in SPV clients.

The privacy leaks in BIP 157 are much fewer than BIP 37, as the only information leaked is what blocks your client is looking at, nothing else.

BIP 158 provided a structure for compact filters to use on block data, but its size and false positive rate was not the best, a recent proposal by developer Aleksey Karpov describes new filter types on blocks data.

The new BIP provides an example for the false positive rates testing 10000 addresses in monitoring for 2000 blocks, the old BIP 158 had 32 false positives with filter size of 36.64Mb, downloading about 68.64 Mbs of data. The new BIP had 0 false positives with filter size of 57.64Mbs, providing a bandwidth consumption reduction of about 16%.

The new BIP also provides space saving by the use of batching and separation of filters by address type.

If you’d like to check out the specifications of the new BIP or follow the discussion, please refer here.

Reconciling the off-chain and on-chain models with eltoo

Eltoo is a simple Layer 2 protocol that improves on the current protocol by removing the need to have a penalty, using the clean separation of protocol layers provided by eltoo, a reconciliation of many on-chain and off-chain concepts can be done.

The UTXO model and the transaction structure concepts can be used to represent the negotiation layer with operations like redistributing funds, joining and splitting in an arbitrary fashion without the rest of the contract being involved.

We could use Bitcoin transactions to collaboratively manage funds bound to some outputs and change their ownership and allocation over time, representing off-chain negotiations and presenting it to a group of participants in an off-chain contract.

This allows us to reuse a lot of tool that were built for on-chain transactions in off-chain negotiations.

If you’d like to read more about Eltoo, you can read its paper here and follow the discussion on this here.

Resources

• Discussion on Fraud Proofs
• Discussion on Block Batch Filters
• Eltoo Paper
• Eltoo Discussion