While working on Bulletproofs++ I realized there were gaps in my understanding of zero-knowledge proofs. I did a quick search through the literature to find proofs for zero-knowledge that can help my understanding. I found that either the protocols were too different to Bulletproofs(++) or the proofs seemed incomplete.

For example, in Bulletproofs, removing blinding values from the protocol does not affect the proof. This would make it seem like the changed protocol is ZK, but upon closer inspection, it isn’t.

To help developing an intuition for ZK, I created a little demo proof for a toy ZK protocol. You can find at at

https://github.com/jonasnick/little-crypto-notebook

The toy protocol is a heavily simplified variant of Bulletproofs range proofs. In short, it proves that a committed value is the product of two other committed values.

I hope you find the demo useful too. My goal is to continue expanding the little crypto notebook if time permits.

Abstract: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&P’19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.

In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.

Read more on the Blockstream Blog.

1. BIP-Schnorr Abstract: This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve secp256k1.

2. BIP-Taproot Abstract: This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.

3. BIP-Tapscript Abstract: This document specifies the semantics of the initial scripting system under BIP341 [BIP-Taproot].

Some highlights:

• 2018-01-23: Taproot idea is proposed
• 2018-04-28: Work on BIP-Schnorr and what was known as “BIP-metas” (MErkle branches, TAproot, and Schnorr signatures) begins
• 2018-07-06: BIP-Schnorr draft is published
• 2018-09-25: libsecp256k1 schnorrsig PR opened
• 2019-05-06: BIP-Taproot and BIP-Tapscript proposals are published
• 2020-01-21: Bitcoin Core taproot PR opened
• 2020-09-11: libsecp256k1 schnorrsig PR merged
• 2020-10-15: Bitcoin Core taproot PR merged
• 2021-05-01: Bitcoin Core release with “Speedy Trial” activation parameters
• 2021-06-13 (block 687456): Taproot LOCKED-IN
• Block 709632: Taproot activation

Protip: If you have troubles memorizing BIP numbers (like me), achow101 observed that BIP-Taproot’s number, 341, are the reversed digits of BIP-143. The segwit version 0 transaction digest is defined in BIP-143 and version 1 digest is defined in BIP-341.

Abstract: MuSig is a multi-signature scheme for Schnorr signatures, which supports key aggregation and is secure in the plain public key model. Standard derandomization techniques for discrete logarithm-based signatures such as RFC 6979, which make the signing procedure immune to catastrophic failures in the randomness generation, are not applicable to multi-signatures as an attacker could trick an honest user into producing two different partial signatures with the same randomness, which would reveal the user’s secret key.

In this paper, we propose a variant of MuSig in which signers generate their nonce deterministically as a pseudorandom function of the message and all signers’ public keys and prove that they did so by providing a non-interactive zero-knowledge proof to their cosigners. The resulting scheme, which we call MuSig-DN, is the first Schnorr multi-signature scheme with deterministic signing. Therefore its signing protocol is robust against failures in the randomness generation as well as attacks trying to exploit the statefulness of the signing procedure, e.g., virtual machine rewinding attacks. As an additional benefit, a signing session in MuSig-DN requires only two rounds instead of three as required by all previous Schnorr multi-signatures including MuSig. To instantiate our construction, we identify a suitable algebraic pseudorandom function and provide an efficient implementation of this function as an arithmetic circuit. This makes it possible to realize MuSig-DN efficiently using zero-knowledge proof frameworks for arithmetic circuits which support inputs given in Pedersen commitments, e.g., Bulletproofs. We demonstrate the practicality of our technique by implementing it for the secp256k1 elliptic curve used in Bitcoin.

Read more on the Blockstream Blog or watch the pre-recorded talk we presented at the CCS 2020 conference.

There are two posts I recently contributed to Blockstream’s engineering blog expanding on the talk I gave at The Lightning Conference 2019. Cross-posting them here because they fit the theme of this blog:

• Reducing Bitcoin Transaction Sizes with x-only Pubkeys

  This article is about the recent introduction of so-called x-only pubkeys to the Bitcoin Improvement Proposal BIP-schnorr […] significantly reducing the weight of every transaction output without any loss in security. By removing the Y-coordinate byte from compressed public keys currently used in Bitcoin, public keys end up with a 32-byte representation. We are going to look at how it works, why that’s useful, and sketch a security proof.

• Insecure Shortcuts in MuSig

  Using BIP-Schnorr-based multisignatures, no matter how many signers are involved, the result is a single public key and a single signature indistinguishable from a regular, single-signer BIP-Schnorr signature. This article is about optimizing implementations of multisignature protocols and why seemingly harmless changes can totally break the security.

At Breaking Bitcoin 2019 in Amsterdam I gave a talk about how to build secure protocols on BIP-taproot or more specifically how to avoid the dangers we learned about so far. There was not enough time to cover everything. The talk also gives an introduction to how to use our MuSig implementation in libsecp256k1-zkp. The video recording is on youtube (slides). Thanks to kanzure there’s also a transcript of the talk.

Erratum: MuSig nonces can not be pre-shared. Only nonce commitments. See https://github.com/ElementsProject/secp256k1-zkp/pull/73 for details.

nix-bitcoin (github.com/fort-nix/nix-bitcoin) is a project I contribute to in my spare time that provides nix packages and nixos modules for easily installing Bitcoin nodes and higher layer protocols. The initial idea was to build myself a lightning node in a reproducible way. I talked more about the motivation and how to use it at the LightningHackdayMUC (video, slides).

Last weekend a bunch of hackers assembled for the 3rd Lightning Netword Hackday in Berlin. The event was packed with interesting sessions, neat hacks and exciting discussions which were concluded with the traditional dinner & drinks at ROOM77. I gave a talk about “Schnorr and Taproot in Lightning” (slides, video) focusing on privacy and security implications.

At the recent Building on Bitcoin conference in Lisbon I gave a talk about a few new ideas in the scriptless scripts framework. The first part was mainly about blind coinswaps, which is a way to swap bitcoins with a tumbler without revealing which coin are swapped. The second part about how to exchange ecash tokens peer-to-peer using scriptless scripts and Brands credentials. You can find the talk on youtube and the slides here. Thanks to kanzure there’s also a transcript of the talk.

EDIT: I’ve added a note about the security of Blind Schnorr signatures against forgery to the slides. In short, a naive implementation of the scheme is vulnerable to Wagner’s attack. An attacker can forge a signature using 65536 parallel signing sessions and O(2^32) work.

Last week the Monero team disclosed a major bug in CryptoNote based cryptocurrencies (reddit thread) which could be used to create “create an infinite amount of coins”. Monero itself was quietly fixed in February (release, pull request) and the since then every user syncing the blockchain from scratch validates that it was never exploited in Monero. However, it was used in CryptoNote based shitcoin ByteCoin to create about 700 million coins out of thin air.

There are already a few good explanations of the bug, for example at the Monero StackExchange and the modern crypto mailing list. This article gives additional background about the signature scheme and the properties of the curve that allowed this bug to slip in.

Apart from the value at stake, this bug is interesting because it shows the risks of breaking a specialized cryptosystems such as Ed25519 apart and apply the parts in other contexts. Ed25519 is designed for plain cryptographic signatures and the curve it is based on is used in CryptoNote to implement one-time ring signatures. In contrast to a regular signature scheme, one-time ring signatures using the curve require that part of the signature does not generate a small subgroup. Ensuring this is necessary when using curves with a cofactor. CryptoNote did not do that.