Bitcoin’s Taproot
Getting more from less
In early May 2019, Pieter Wuille, a prolific Bitcoin Core contributor from Blockstream, quietly introduced a pair of BIPs (Bitcoin Improvement Proposals) that describe a new address scheme called Taproot. The proposals build on the Schnorr signature and Scriptless Scripts work that I discussed in prior posts and provide the required implementation details for them to become a reality. This unlocks many interesting possibilities for developers and marks an important step forward for Bitcoin.
Taproot not only allows the benefits from the prior concepts: enabling compact multisig and scriptless smart contracts, it goes one step further and allows an additional backup script to be specified and revealed only if needed. This backup script does not consume more space on the blockchain and is not even detectable unless it is needed. These techniques promise to be a boon for privacy, scalability, and flexibility.
Background
Bitcoin is the first and in many ways the simplest cryptocurrency out there. This is often thought of as a weakness since it’s harder to implement more complex ideas within Bitcoin. However, it can also be seen as a strength as the system is simpler and simple avoids many kinds of bugs. Plus, there are many efforts to introduce important building blocks for developers such as Taproot and the technologies it enables.
UTXOs
Bitcoin’s scripting language is deliberately limited, and each currently unspent bitcoin is tracked separately within an unspent transaction output or UTXO. UTXOs are bound to spending conditions that existed when the UTXO was created. UTXOs are stateless, so it’s not obvious how to implement many kinds of smart contracts. In Bitcoin, common spending conditions for a UTXO are a transaction signature by single key.
MAST (Merkilized Abstract Syntax Trees)
Bitcoin currently has the ability to encode complex logic to handle various spending conditions. This functionality is called Pay to script hash (P2SH). P2SH requires the recipient to create a script, compute a cryptographic hash of the script, and then commit that it by creating an address. To spend payments to the address, the recipient later must reveal the script that when hashed equals the original hash included in the address, as well any needed inputs to satisfy the script.
P2SH works well, but has a rather major downside that the entire script must be revealed when it comes time to spend funds. This is suboptimal for both privacy as well as scalability reasons. MAST, which was originally proposed in a 2014 paper from MIT, uses the power of Merkle trees to allow us to reveal only the branches needed to prove the script is satisfied. This approach means unused branches are never publicly revealed. Much larger and more complex scripts with many spending conditions can now be implemented efficiently, without revealing all possible spending conditions.
Schnorr & Scriptless Scripts
Schnorr signatures allow multiple signers to combine their keys together to a form multisignature key which creates an address. This multisignature key is then used on the blockchain, but is indistinguishable to others from a single key.
Andrew Poelstra showed us how we can use these multisignature keys to create a special kind of smart contract where computation does not happen on the blockchain. Rather, parties must come to the conclusion on their own and only then publish the result to the blockchain where it is verified.
Taproot
The Taproot proposal offers a spec for how Schnorr signatures can be used within SegWit (Segregated Witnesses) addresses. This ability to add new signature schemes was one of the main drivers for pursuing SegWit in the first place.
In addition to offering a concrete specification allowing us to use MAST and Schnorr, Taproot uses a cryptographic technique to combine both into a single address. It’s possible to take the public key of a Schnorr address and ‘tweak’ it with a script. These addresses do not look different than ordinary Schnorr addresses. The fact that there’s a hidden script inside is not knowable unless it is needed.
To illustrate one simple potential use case. Imagine Alice wants to give Bob a long term gift. Bob is not to spend the coins for at least 5 years. Alice can deposit to a Taproot address where the spending conditions are either Alice + Bob’s multisig (everyone agrees case), but she also includes a hidden backup script that specifies the actual spending conditions (CheckSequenceVerify for 5 years + Bob’s signature). Once 5 years go by, Alice + Bob can sign together for a very efficient, compact and privacy preserving transaction. Nobody would be able to tell the underlying conditions or even who was involved in spending it. However, if Alice is not available or decides not to cooperate down the line, Bob can claim the money by revealing the script, which would result in a larger transaction that does reveal the spending conditions.
With a single address type, you can pay with either the public key or the hidden script. If the public key is a multisig, then the signature is indistinguishable from a signature from a single key. It’s expected that this will often represent the “everyone agrees” case.
Taproot is a natural progression of the idea that the blockchain should only be an arbiter of disputes, and computation should largely not take place on the blockchain itself. Rather, computation on the blockchain should be seen as a last resort measure and only utilized upon disagreement.
What’s next?
Incorporating Bitcoin consensus changes has historically been challenging, but these proposals should be less controversial than many others. As a soft-fork, they do not affect current nodes’ ability to validate the blockchain without upgrading. Miners will need to upgrade to ensure that the chain does not fork. Also in Taproot’s favor, is that these features are purely optional from the users’ perspective. If a user does not want to utilize this functionality they are not forced to.
We should expect a several month review period where cryptographers and developers provide feedback on the proposals. Then we will likely see several months of developer work and integration into Bitcoin’s testnet. If all goes well, this functionality may hit Bitcoin’s mainnet sometime in late 2020 or 2021.
