Schnorr and Taproot
Bitcoin’s favourite new toys
Protocol changes to bitcoin generally have been few and far between, with a developer ethos of ‘quality over quantity’ largely responsible for the networks stability and success. Updates go through the long and rigorous BIP process, before being tested and deployed if the consensus approves of the particular proposal. One of these proposals being contemplated by the core development team at the moment is the new Schnorr signatures BIP, proposed by Peter Wuille.
The Schnorr signature BIP is based around the implementation of Schnorr signatures in bitcoin. Currently bitcoin uses Elliptic Curve Digital Signature Algorithm (ECDSA) signatures for authenticating transactions. Schnorr signatures are a potential alternative mechanism for signing transactions, providing a number of benefits over ECDSA signatures. These are split into the following 3 benefits in the BIP as follows:
- Security
The superior security of Schnorr signatures is demonstrated in the usage of a cryptographic model called the ‘random oracle’ model. Without delving too deeply into the model, Schnorr signatures are provably secure within the bounds of the random oracle model, whilst ECDSA signatures are not provably secure within random oracle. The implication from this is pretty simple — Schnorr signatures are more secure than their ECDSA counterparts.
2. Non-Malleability
ECDSA signatures are malleable in that a third party without private key access can alter an existing valid signature for a given public key and message into another valid signature for the same key and message. This has been a major concern in past BIPs, and in essence isn’t a solvable problem without transitioning away from ECDSA. Schnorr signatures are provably non-malleable, and thus solve the malleability problem.
3. Linearity
Linearity is where a lot of the value add of Schnorr is, providing the building blocks of more efficient and private transaction signatures. In simple terms, multiple parties can collaborate to produce a signature that is valid for the sum of their public keys.
Putting it into more basic terms, Schnorr signatures provide a way for Bitcoin transactions to be more efficient and private. The diagram below shows the ECDSA signatures of the current protocol, note that the multisig transaction signature requires three separate signatures to be a valid transaction.
In the Schnorr implementation of the same transactions shown above, the multisig transaction requires just a single merged signature, greatly reducing the bandwidth and storage burden on the protocol of these transactions. In ECDSA signatures, identities are freely available from multisig transaction signatures. In Schnorr, transaction signers can be completely private.
Schnorr as a space saving Mechanism
Because Schnorr only benefits the efficiency of multi signature transactions, the exact capacity saving benefits are hard to measure. Bitmex Research summarises the performance benefits of Schnorr in the following two statements:
Economic usage of multi-signature technology is far more prevalent than by merely looking at the UTXO count. Around 21.5% of all Bitcoin is stored in multi-signature wallets, a far higher figure than the 5.9% adoption by UTXO count
Multi-signature adoption is growing rapidly, as the below chart indicates. While at the same time new systems like the lightning network require multi-signature adoption and with Schnorr signature making multi-signature systems more powerful, adoption is likely to increase
Schnorr and Taproot in Smart Contracts
At the moment when someone builds a smart contract into the Pay to Script Hash (P2SH) system, all of the possible permutations of the contract are revealed the moment the outputs of the transaction are spent. Aside from the obvious privacy implications of revealing the entire contract to the public blockchain, this is also inefficient from a storage perspective, as each possible outcome takes up space.
In 2016 the Merkelized Abstract Syntax Tree (MASTs) was introduced by Bitcoin protocol developer Johnson Lau, providing a method for multiple spending conditions in Bitcoin transactions. These conditions are structured and hashed such that they only need to be revealed if they are used. However, MASTs are limited in that they reveal the presence of the other spending conditions. In the example shown below, if one were to utilise the spending conditions on the left branch, the MAST would also require the hashes from the right branch to be included in the transaction. This reveals the presence of the more complex alternative spending conditions, and has similar privacy and efficiency issues as typical P2SH transactions.
The issues of MASTs have since been addressed in Taproot — a proposal first defined in an email by Greg Maxwell in 2018. Taproot operates on a similar premise to MASTs, dividing transaction spending conditions into merkle tree hashes. Where it differs is in the amount of information provided by the transaction published to the blockchain, as Taproot constructions only provide a single tweaked public key, generated by a combination of the Merkle root of the spending conditions and the original public key. Since only a public key is provided publicly, the transaction appears as just the same as a typical 1:1 Bitcoin exchange.
Taproot thus allows for these complex transactions to be pushed to the blockchain privately and efficiently, only revealing the tweaked public key. Whilst some have suggested this enables smart contracts on bitcoin, these complex transactions have been possible through P2SH since BIP16. This update simply makes such transactions more palatable.
Taking a broader view, we anticipate few issues with both Taproot and Schnorr passing protocol consensus. Neither update has significant downsides and can be considered ‘win-win’ from a protocol perspective. Given the support it has from core members of the development team, it shouldn’t be surprising to see this fork sooner rather than later.
