Bitcoin After Taproot
Taproot, Bitcoin’s biggest upgrade since Segwit in 2017, activated last night. It has taken years to get to this point but this upgrade opens the door for multiple other innovations to occur that are being worked on in parallel.
Taproot
Taproot is actually three upgrades in one that have been under discussion since 2012 with the first BIP written in 2016. At its core, it increases scalability of Bitcoin slightly, improves privacy for users but particularly for multisigs, and allows for a lot more features to be enabled in the coming years.
BIP 340 — Schnorr Signatures
Bitcoin currently uses ECDSA signatures but will be transitioning to Schnorr signatures now that the patent has expired. River does a good step by step explanation as seen below but the TLDR is that public key aggregation makes multisig, and by proxy Lightning users, indistinguishable from regular single sig bitcoin transactions. This is achieved by aggregating the public keys of the multisig into a new combined public key. This means that you will not need to show the 2 of 3 public keys (AB of ABC) to sign a transaction as public key ABC will represent any combination of ABC (AB, AC, or BC). The savings scales to any m of n configuration.
BIP 341 — Taproot
This is the BIP that is the actual Taproot part of Taproot. It introduces a new script type (Pay to Taproot or P2TR) that handles the logic of paying to a Schnorr public key or Merkle Root by satisfying the conditions of a script. It does this through the Schnorr BIP mentioned above and the introduction of MAST (Merkelized Alternative Script Tree formally known as Merkelized Abstract Syntax Trees). MAST allows for much more complex things to be done with Bitcoin akin to smart contracts on other chains. The maximum depth of a tree is 32 rows which in layman's terms means a maximum of four billion scripts can be created yet only one needs to be met for the coins to be spent. That will be the one published onchain and the other conditions will never be exposed vastly increasing the privacy of users by not exposing the spending conditions of the transaction. Today, all of the conditions are exposed which means you can tell if something is a lightning channel or the pubkeys used to construct a multisig.
Again, River has a good diagram to explain that your 50 million sats with Taproot public key Q can be spent either by Schnorr public key P or by any of the script conditions of public key M.
BIP 342 — Tapscript
Tapscript is the thing that hold these all together by verifying the scripts of Taproot spends and Schnorr signatures. It does so by introducing several new op codes in a flexible manner that allows for more seamless upgrades in the future.
What’s not in Taproot
Unfortunately Cross Input Signature Aggregation was left out of this upgrade. As Pieter Wuille put it in 2018:
With the emergence of so many ideas for improvements to Bitcoin’s script execution (MAST, Taproot, Graftroot, new sighash modes, multisignature schemes, …) there is simply too much to do everything at once. Since aggregation really interacts with all other things, it seems like the better choice to pursue later.
However, once CISA is merged, incentivised coinjoins become a reality as part of that fork. That is because the signature cost savings of multiple signers becomes cheaper than a single signature spend.
What does this mean for me?
Basically nothing because it will take about a year for enough wallets to begin supporting Taproot. Once Taproot is activated at block 709,632 wallets will begin updating their software to include Taproot. This should not require you to create new seeds and be a similar experience to the segwit upgrade in 2017 where you were presented with two address types to choose from. The only change you’ll see as a user is that addresses change from a bc1q to bc1p for the bump to segwit v1.
Can I do something to take advantage of Taproot?
Personally I would recommend moving your old UTXOs from the previous address formats to Taproot as long as the mempool stays clear so you can save some money on future fees. This is especially true for anyone who has or has been thinking about using a multisig set up as they will gain the most from this upgrade. How does it achieve this level of savings? In order to spend from a current address, you need to include the public key in the input. Taproot includes the public key in the output being spent (hence the increase in output size) but saving space on the input. Most of the space savings comes from Schnorr being the default signature scheme used hence the multisig recommendation.
You may be thinking, “why would I pay a transaction fee to hodl my sats rather than pay the fee at the point of using them?” I thought the same thing at first but as Murch pointed out, the mempool has been clear for most of 2021 and you can get a transaction in at 1 sat per byte. Even at the second spend, you are saving money once fees reach 2 sats per byte. So if you have a wallet that allows for Taproot receiving, you should send it there, move old UTXOs when the mempool is empty, and take advantage of the privacy benefits of multsig with Taproot.
How does it improve privacy? Bitcoin Op Tech looked at block 692,039 for multisig use. They broke down the threshold needed such as a 2 of 2 spend like Lightning uses or a common 2 of 3 multisig by color. If these multisig wallets would use a keypath spend rather than a more complex script, they become indistinguishable from a single signature wallet. You also would not be able to isolate specific applications such as Liquid which uses an 11 of 15.
Schnorr and Taproot allows for:
Scriptless Scripts
This is a way to encode smart contract information into signatures. Frankly a lot of this goes over my head and I have to watch it twice to understand but this impacts a lot of things that you can hear about here. Andrew Poelstra unfortunately is not on Twitter but is someone worth following their work if you ever see him on a podcast or panel to keep up with the latest developments as it touches on many of the things listed below.
MuSig
MuSig is a family of Schnorr based multisig set ups. I say family because there are currently three version, MuSig, MuSig2, and MuSig-DN. You will likely see MuSig2 implemented based on its ease of use. All three versions unfortunately are only n of n setups so this could be adopted by Lightning which is a 2 of 2 multisig but will not be used for m of n set ups like Casa’s 2 of 3 wallet. There are people working on threshold set ups to enable this eventually.
Adaptor Signatures
An adaptor signature is a way to combine signature data with a hidden value to reveal a signature or with the signature reveal the hidden value. This enables several uses cases around how contracts are locked and executed in a more efficient and private manner. Two such examples are around coinswaps or atomic swaps as both parties can reveal data at once in a trustless manner and if all is well, the transaction goes through. These are technical explainers but here is a quick one with Rene and a longer one around DLCs.
PTLCs
Another great use of Adaptor Signatures are Point Time Lock Contracts (PTLCs). This is one possible upgrade to Lightning that currently uses HTLCs which would be beneficial to users privacy by eliminating the link ability of transactions and making it harder to understand which nodes are routing nodes. It does this by not using the same scripts and using the signature derived from the adaptor signature and something called a scalar. This does not give Lightning users perfect privacy but makes it much harder to track especially when coupled with multipath payments. You can watch a PTLC demo here.
DLCs
Discrete Log Contracts can be done now but much more efficient with Taproot. These are a contract where a party is betting on the outcome of an event. This can be as a way to bet on sports teams, create bounties, etc. Someone will make a prediction and an oracle will sign off on the outcome. The party that meets the conditions of the outcome can then claim the funds. This can be done today with Krystal Bull by Suredbits on your desktop or on your Umbrel node (demo video here).
BIP118: AnyPrevOut
Formally known as SIGHASH_NOINPUT, it was updated to be called SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT. The changes are small but the main takeaway is that that the current BIP takes advantage of an upgrade path laid out in BIP342 for tapscript. So while this technically does not need Taproot to be merged, doing so post Taproot removes the need for its own segwit version. For context, when segwit was introduced, it laid out 16 version numbers. The segwit addresses you have been using since 2017 that start with bc1 is segwit v0. Taproot was the first upgrade that bumped it to segwit v1.
So what is AnyPrevOut? It’s a proposed upgrade that signs most of the transaction but not the inputs of the the transaction. This allows for a specific kind of spend where any input that satisfies the script with that public key can be used or for inputs to be swapped if needed. This allows for some flexibility in spending conditions, scalability through efficiency, and allows for some interesting things to occur once merged. You can learn more here.
Eltoo
One of the things that AnyPrevOut enables is Eltoo, an enforcement function for the Lightning Network that could replace LN-Penalty. The primary benefit to the Lightning Network is that you would no longer need to keep track of the channel backup data for every routed transaction that can be unsafe. However, Eltoo also reduces onchain costs, eliminates some of the security concerns between counterparties, and simplifies channel factories. The efficiency gained from channel factories would allow for multiple users to open lightning channels with a single UTXO. You can learn more about BIP 118 and Eltoo from Christian Decker.
CoinPool
Another idea that can be implemented once AnyPrevOut is merged is a CoinPool. This is similar to the JoinPool proposal (explained further down) but this takes advantage of the Taproot specifically. By allowing multiple parties to share a single UTXO that is also indistinguishable from other UTXOs, it allows for more private versions of Lightning, vaults, and other features as you can no longer determine which participant of the UTXO is making the transaction as you can no longer assume it is one entity.
BIP 119 OP_CTV
OP_CHECKTEMPLATEVERIFY is a proposed BIP that creates a new opcode that seconds conditions on how coins are spent. This enables several uses cases that can use this emergent property from scaling solutions, financial services, etc. An easy example is an inheritance plan. If you are the only one in your family that understands Bitcoin and you don’t want your family to immediately sell your coins if you die tomorrow, you could use this to instruct a wallet to spend 10% of the stash, every year, for 10 years, to a specific address. This way your family benefits from the presumed upside in price over 10 years and forces them to hodl by setting a maximum spend per year.
TLUV Covenant proposal
Conversely, AJ Towns recently proposed a similar idea to BIP 119 called OP_Tapleaf_Update_Verify. This replies on the Taproot upgrade and one use case is a joinpool. This is where multiple people all share a single UTXO creating unique privacy implications that breaks more on chain surveillance assumptions. The main advantage over OP_CTV is that users can exit on their own without requiring signatures from everyone in the pool making it easier to operate and saves on fees from signing those transactions.
Other possible updates to Bitcoin beyond Taproot:
Stratum v2
Stratum v2 is an upgrade to how mining pools work. Proposed by Pavel Moravec, Jan Capek, and Matt Corallo, this enables further decentralization by improving upon how smaller at home miners can communicate with mining pools in a more secure manner. Moreover, it allows for individual miners to mine their own block and include a different subset of transactions than the block being proposed by the pool as a collective. This gives hobbyist miners more flexibility and allows for more censorship resistance of the network as they no longer have to abide by the rules imposed by a pool.
Erlay see BIP330
Erlay is a proposed upgrade on how nodes relay unconfirmed transactions. The paper written by Gleb Naumenko, Pieter Wuille, Gregory Maxwell, Sasha Fedorova, and Ivan Beschastnikh it suggests a bandwidth savings of over 80%. It would also allow for the increase in the number of outbound connections your node could make. This would protect users from certain kinds of attacks as well as improve your privacy.
If anyone more technical than I am sees anything wrong with the above, please DM me for corrections and check out Bitcoin Op Tech which is a newsletter from developments happening in the space. I used their site a lot to fact check myself and provide additional links.
