Skip to content

Instantly share code, notes, and snippets.

View markblundeberg's full-sized avatar

Mark B Lundeberg markblundeberg

  • Wet coast, Canada
View GitHub Profile
@markblundeberg
markblundeberg / instaconf.md
Last active February 22, 2018 07:46
Buy your coffee with InstaConf: nearly trustless zero-confirmation guarantees

Buy your coffee with InstaConf: nearly trustless zero-confirmation guarantees

A proposal by Dr. Mark B Lundeberg, 2018 Feb 21 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

This is a proposal for reducing the risk of accepting unconfirmed (zero-conf) transactions in Bitcoin-like cryptocurrencies. Accepting such transactions is typically safe, however there is always the risk of [double-spending](

### Keybase proof
I hereby claim:
* I am markblundeberg on github.
* I am marklundeberg (https://keybase.io/marklundeberg) on keybase.
* I have a public key ASDQpnjba7VyKnEj28AwOYk3TzhbWeUP-KJbFs3XesNWlgo
To claim this, I am signing this object:
@markblundeberg
markblundeberg / notification.md
Last active January 7, 2019 17:23
BCH 24-bit public notification addresses

This is a brief specification proposing the use of short anyone-can-spend P2SH addresses. This protocol is already in use with BCHMessage as used in OpenSwap, for the 'public bulletin boards' feature, but may be of use in other protocols.

Rationale

Various protocols like on-chain messaging, payment codes, and so on need SPV-wallet-friendly notifications.

  • In BIP47, notifications are sent to an address owned by the recipient, which means that notifications create UTXO dust. If the UTXO dust is cleaned up, this causes a privacy concern as its destination can be traced. If not cleaned, then the UTXO set will grow and grow over time. BIP47 v2 tried to solve this by using a 1-of-2 multisig so that the sender can also clean up the dust, however this creates SPV unfriendliness for the recipient.
  • In stealth addresses, payments are tagged with an OP_RETURN including a few-byte prefix that can be use
@markblundeberg
markblundeberg / alt_cms.md
Last active February 2, 2019 01:19
Alternative OP_CHECKMULTISIG mechanics for Schnorr

Currently with OP_CHECKMULTISIG we have the following N-of-M mechanics (legacy mechanics), illustrated by a 2-of-3 example:

  • Locking script: OP_2 pubkey_alice pubkey_bob pubkey_carol OP_3 OP_CHECKMULTISIG
  • ScriptSig (N+1 pushes): OP_0 sig_alice sig_carol (OP_0 is the dummy element)

This is a rather bad mechanism, where sig_carol needs to be checked against both pubkey_bob and pubkey_carol. As discussed elsewhere, this is a disaster for Schnorr batch verification. So in the May 2019 upgrade, we're going to make it so that the signatures sig_alice and sig_carol are not allowed to be Schnorr signatures. I mean, we could allow them to be Schnorr and just use single-checking, but we have better plans in mind...

Schnorr signature aggregates (with OP_CHECKSIG) are really cool but they aren't a replacement for OP_CHECKMULTISIG. So, we need a new way that at least allows for batch verification.

Our goal is to make it so that all UTXOs can be spent with Schnorr, and that includes multisigs. It is unthi

@markblundeberg
markblundeberg / transcript.txt
Created May 19, 2019 04:20
transcript from Schnorr multisig with checksum0 and Chris Pacia
(https://github.com/markblundeberg/schnorrfun)
********************
Schnorr multisigger!
********************
Warning: this is for DEMONSTRATION and does not necessarily use safe/secure
techniques. Beware, funds can be easily lost!
@markblundeberg
markblundeberg / bip62_and_schnorr.md
Last active December 13, 2019 22:39
BIP62 and Schnorr: a new era in BCH privacy and smart contracting

Two new features are coming to Bitcoin Cash soon, hopefully in the May 2019 upgrade. I'd like to take the time to explain why I'm so excited about them. In short, we will be able to do:

  • Payment channels hidden as ordinary payments.
  • Atomic swaps hidden as ordinary payments.
  • Lightning-style payment channel networks too, if we want.
  • Secure chains of unconfirmed transactions involving multiple parties (layer 2).

That all may sound incredible, and I'm going to explain in this document how it is so.

--- Mark B. Lundeberg, 2019 Jan 29 bitcoincash:qqy9myvyt7qffgye5a2mn2vn8ry95qm6asy40ptgx2

@markblundeberg
markblundeberg / devabc.md
Last active February 5, 2020 15:43
ABC dev notes

Basic building: first mkdir build-ninja in repo root, then run cmake -GNinja .. within the new directory, then ninja check-all.

Build with clang:

CC=clang CXX=clang++ cmake -GNinja ..

Build with debug:

CC=clang CXX=clang++ cmake -GNinja .. -DCMAKE_BUILD_TYPE=Debug
@markblundeberg
markblundeberg / schnorrblind.md
Last active November 28, 2020 01:30
Blind Schnorr signatures

Blind Schnorr signatures

Requester has a message-hash m that they want to be signed by pubkey P that is owned by Signer (who knows P = xG for private key x and generator G).

The following is a direct adaptation of Matthew Green's blind scheme adapted for the specific case of bip-schnorr elliptic curve signatures (including the sign-flip factor) and has been used in the wild (for internal protocol message signing, not for transaction signing) since late 2019 in the BCH CashFusion protocol.

Symbols:

  • R R' P G are elliptic curve points. Additive convention is used.
  • n is the curve order.
  • a b e e' i j k s s' x are integers mod n.
@markblundeberg
markblundeberg / covenant_noinput.md
Last active February 5, 2021 20:05
BCH floating transactions: SIGHASH_NOINPUT emulation using CHECKDATASIG covenants

BCH floating transactions: SIGHASH_NOINPUT emulation using CHECKDATASIG covenants

A new sighash flag has been proposed (originally for Lightning, now for Eltoo) which redacts information about the spending inputs, most notably their transaction IDs.

This facility is both powerful and dangerous: it means that signatures intended for one transaction can be used on other transactions. It also makes up a very strong increase in the malleability of transactions. SIGHASH_NOINPUT allows for much more flexible off-chain smart contracts than nonmalleable transactions. Note that Eltoo requires SIGHASH_NOINPUT, for instance. It's not clear whether such a dangerous feature will be adopted on BCH any time soon.

In this gist I'm going to explain that CHECKDATASIG covenants let us write smart contracts that emulate SIGHASH_NOINPUT. This capability alone should in principle allow to build Lightning, Eltoo with bilaterally funded smart contracts on BCH (though, with some significant

@markblundeberg
markblundeberg / tapbch.md
Last active August 18, 2021 21:08
How might Taproot be implemented in BCH, and do we need it?

Taproot is an interesting technology to enable multiparty privacy on a bitcoin. Currently, there is a problem with multiparty contracts in that they are obvious deviation from the most common script type (P2PKH), which hurts privacy. The script that gets used will typically indicate exactly what kind of protocol was at play. Also complex P2SH scripts take extra resources (transaction size and CPU cycles).

The basic idea with Taproot is that instead of P2SH where a script is committed by a hash, you can hide a script (or set of possible scripts) as a commitment within a normal-looking public key. Now there are two ways to spend from this public key:

  1. Create a normal transaction signature using the public key, or,
  2. Reveal the commitment, and provide parameters that satisfy the revealed script.

To do #1, it means you need to know the private key, or, you have a set of signers who are able to produce a signature (that's where Schnor