RubenSomsen

Introduction

I'm Ruben Somsen, Bitcoin Sorcerer. I do protocol design in order to enhance Bitcoin.

I'm sponsored by Spiral, Superlunar/Gemini, HRF, and am currently working on Silent Payments with Josie and assisting Davidson with the implementation of Proof-of-Work fraud proofs into Floresta.

I also help maintain the bitcoin-dev mailing list, am a BIP editor, co-hosted the Unhashed Podcast, founded the Seoul Bitcoin Meetup in 2014, actively co-organizing BitDevs Amsterdam, and on the layer two funding sub-committee of OpenSats.

You can find me on Twitter, Mastodon, and Telegram. You can also join [this Te

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.

15-minute talk summarizing the protocol

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.

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

RubenSomsen

Liquid P2P Loans

This is a variation of the Hodl Hodl contract design for Liquid, but without an arbitrator (not counting Liquid itself). It's pretty simple and similar ideas exist, but it seemed interesting enough to write up and spur some conversation.

I'll begin by explaining the high level concept. For the full details, please examine the steps in the diagram below.

Concept

A contract where the Borrower puts up 1.5x collateral (e.g. 1.5 L-BTC) in order to borrow another asset (e.g. $10k USDT, if we assume that's the price of 1 L-BTC). The borrower can reclaim the collateral if they pay back the loan before expiry. If expiry is reached, the collateral goes to the Lender.

Use cases

• Spending L-BTC without necessarily selling, which

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

The Tragic Tale of BIP30

Bitcoindev mailing list thread here, podcast discussion 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 altog

RubenSomsen

Blind Merged Mining with covenants ( sighash_anyprevout / op_ctv )

Update: the content of this gist is also explained in this Spacechains video.

This write-up was also published on bitcoin-dev.

Blind Merged Mining (BMM) is the idea of committing the hash of another blockchain into a unique location on the Bitcoin blockchain, and paying a Bitcoin fee to miners for the privilege of deciding this hash and capturing the fees inside the other blockchain. Since miners don’t have to know what the hash represents and are simply incentivized to choose the highest bidder, it requires no extra validation on their part (“blind”). This idea was originally conceived of by Paul Sztorc, but required a specific soft fork. [0]

In essence, BMM is a mechanism that allows external blockchains (altcoins, tokens) to outsource their mining to the Bitcoin blockchain. Instead of burning electricity with ASICs, th

RubenSomsen

SAS: Succinct Atomic Swap

Works today with [single signer ECDSA adaptor signatures][0], or with Schnorr + MuSig.
Other than the explanation below, there's also a diagram and a video.

 
Advantages:

• Requires merely two on-chain transactions for successful completion, as opposed to four
• Scriptless, and one of the chains doesn't need to support timelocks
• Can be used for efficient privacy swaps, e.g. [Payswap][1]

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