Bitcoin After Taproot

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.

Source: River

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.

Source: River

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:

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.

Source: Murch
Source: Twitter answer

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.

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.

Visualisation of distribution change after empowering miners. Source: Braiins

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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Raymond Durk

Raymond Durk

Making shoes you love @atoms. Under caffeinated and over connected. MBA in Sustainability. Please consider the environment before printing this tweet.