RubenSomsen

The Tragic Tale of BIP30

Bitcoindev mailing list thread here.

Introduction

In my recent exploration of [SwiftSync][1], I came to the realization that [BIP30][2] has an unresolved consensus bug. It seems this bug can't be triggered without a reorg back to 2010, so its seriousness is debatable. We currently have checkpoints up to 2013, preventing such a reorg. Once we fully [remove the checkpoints][3], the bug becomes theoretically (not practically) exploitable.

BIP30 is also a bit of an odd duck in terms of consensus checks in that it involves the entire UTXO set without being related to the spending of inputs. This is inefficient, and complicates the implementation of alternative validation methods such as utreexo, SwiftSync and quite possibly ZKP systems such as ZeroSync. It would be nice if we could sunset BIP30 altogether.

RubenSomsen

SwiftSync

Near-stateless, fully parallelizable validation of the Bitcoin blockchain with hints about which outputs remain unspent. All other inputs/outputs are efficiently crossed off inside a single hash aggregate that only reaches zero if validation was successful and the hints were correct.

Introduction

Validation is at the heart of Bitcoin. Any improvements in validation speed will have a direct impact on the scalability of the system, including everything that is built on top of it. For this reason improving validation performance may be one of the most important things we can do.

The generalized observation of SwiftSync is that if we have two sets (in this case the inputs and outputs), and we want to know the difference between these sets (the UTXO set), validating a given answer to this question (the hints) is significantly easier than calculating the answer itself. The novel part here (to my knowledge) is specifically how this can be applied to sets. It seems likely that this observation ca

RubenSomsen

RubenSomsen

Trustless Address Server

Outsourcing handing out addresses to prevent address reuse

Also discussed on bitcoin-dev.

Introduction

Address reuse prevention generally requires interacting with the recipient in order to receive a fresh address for each payment. There are various protocols that ensure no interaction is required such as BIP47[^1] and Silent Payments[^2], though neither is without downsides.

One area that is seemingly underexplored is that of outsourced interaction. BTCPay Server[^3] is an example of this. The sender interacts with a server, which acts on behalf of the recipient and hands out an address from an xpub. The recipient controls and therefore trusts the server, so malicious addresses won't be given out.

RubenSomsen

BIP47 Prague Discussion

This discussion took place at Pizza Day Prague 2022 after a brief discussion on Silent Payments. The main points have been summarized below.

The discussion was mainly between Alekos Filini, Martin Habovštiak, and Ruben Somsen, as well as Daniela Brozzoni, Eric Sirion, Pavol Rusnak, Salvatore Ingala, and others.

This was also posted to the the bitcoin-dev mailing list.

Improving BIP47

RubenSomsen

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Update: This now has a BIP and WIP implementation

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

RubenSomsen

Blind Diffie-Hellman Key Exchange (blind ecash)

The goal of this protocol is for Bob to get Alice to perform a Diffie-Hellman key exchange blindly, such that when the unblinded value is returned, Alice recognizes it as her own, but can’t distinguish it from others (i.e. similar to a blind signature).

Alice:
A = a*G
return A

Bob:
Y = hash_to_curve(secret_message)
r = random blinding factor

RubenSomsen

L2 protocols

Trust protocols (not always auditable)

• Full custody (Coinbase)
• 2-of-3 arbitration / DLC
• Threshold multisig (ecash, Liquid)
• Off-chain peg-out tx (statechains)
• Collateralized custody

Payment channels

RubenSomsen

Segregated Message Signature Scheme (SMSS)

This write-up formalizes a modest adaptation to the regular Schnorr and ECDSA signature scheme, using existing techniques, that allows for signature verification without requiring the message.

The regular signature scheme enables two functions:

1. Proving knowledge of a secret key
2. Tying that proof to a message

Signature verification requires:

• The public key

RubenSomsen

Softchains: Sidechains as a Soft Fork via Proof-of-Work Fraud Proofs

Originally posted on bitcoin-dev.

This post describes a fully decentralized two-way peg sidechain design. Activating new sidechains requires a soft fork, hence the name softchains. The key aspect is that all softchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanism that only requires the validation of disputed blocks. This does increase the validation burden of mainchain full nodes, but only by a minimal amount (~100MB per chain per year). It's similar to [drivechains][0], but without the major downside of having to rely on miners, since all Bitcoin full node users can efficiently validate each sidechain.

Proof-of-Work Fraud Proofs

Last year I posted the idea of [PoW FP to the Bitcoin mailing list][1] ([follow-up here][2]). The idea is that we can use the existence of a fork in Bitc