Skip to content

Instantly share code, notes, and snippets.

Avatar

Ruben Somsen RubenSomsen

View GitHub Profile
View BIP47_Prague_Discussion.md
@RubenSomsen
RubenSomsen / Silent_Payments.md
Last active Aug 11, 2022
Silent Payments – Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead
View Silent_Payments.md

Silent Payments

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

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.

Compared to previous schemes[^1], this scheme avoids using the Bitcoin blockchain as a messaging layer[^2] and requires no interaction between sender and recipient[^3] (other than needing to know the silent payment address). The main downsides are the scanning requirement, the lack of light client support, and the requirement to control your own input(s). An example use case would be private one-time donations.

View Blind-DH-ecash.md

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
View L2_protocols.md

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

View SMSS.md

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
View softchains.md

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

View Spacedollars.md

Spacedollars: Trustless Dollars on a Spacechain

Idea proposed here by Fernando Nieto.

Assuming there is a trustless BTC/USD price oracle, we can burn BTC to create a dollar equivalent amount of "space dollars".

E.g. If the BTC price is $20k, burning 1 BTC gets you 20k space dollars.

The resulting token is the equivalent of the USD: a stable unit of account, but a poor store of value.

@RubenSomsen
RubenSomsen / LiquidP2PLoans.md
Last active May 2, 2022
P2P Loans on Liquid
View LiquidP2PLoans.md

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
View SuccinctAtomicSwap.md

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
RubenSomsen / Resources.md
Last active Jul 20, 2022
Links to my work, accessible via tiny.cc/somsen
View Resources.md

Introduction

I'm Ruben Somsen, Bitcoin Sorcerer. I do protocol design in order to enhance Bitcoin. I also help maintain the bitcoin-dev mailing list, am co-host of the Unhashed Podcast, and I’m organizer/founder of the Seoul Bitcoin Meetup.

I'm sponsored by Spiral, Superlunar, HRF, and am currently working on spacechains with Dhruv.

You can find me on Twitter, Mastodon, and Telegram. You can also join this Telegram group chat to discuss my work. Feel free to ask questions, I want people to understand it.

Bitcoin Sorcery