The Core Question: Why Does Bitcoin Need Segwit and Taproot Modifications?
Segregated Witness (BIP by Pieter Wuile, Eric Lombrozo, Johnson Lau) and Taproot(BIP by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns) are the two biggest changes ever made to the Bitcoin protocol.
The former fundamentally changed the structure of Bitcoin transactions to address the limitations inherent in the previous transaction structure, altering the Bitcoin block in the process. The latter restructured several aspects of Bitcoin’s scripting language, how complex scripts are structured and verified, and introduced new schemes for creating cryptographic signatures.
they are both large scale For example, adding a single opcode like CHECKTIMELOCKVERIFY (CLTV) makes enough changes to allow the receiver to choose to prevent the coin from moving for a certain amount of time.
These changes were made to address the very real shortcomings and limitations of Bitcoin as a system. As a foundational layer for maintaining the global consensus on the overall state of Bitcoin, all unspent coins, Bitcoin is an invaluable and brilliant innovation. As a means of allowing anyone to trade these coins directly, it is woefully inadequate for that purpose.
Several years have passed since Segregated Witness and Taproot were active, and many of the shortcomings they addressed have been forgotten. Even in phone games, over time the reasons and basis for design decisions have become distorted.
Both of these changes to the Bitcoin protocol were solutions to big problems in their own right, but each also solved other problems and laid the foundation for other improvements in the future.
Now that many new people have joined the network since these changes took effect, it’s worth going back and putting your design choices in context.
Sequestered Witness (BIP 141)1)
When a Bitcoin transaction uses a coin, it references the coin by the output index and the transaction ID (TXID) of the transaction that created the coin. This allows you to uniquely identify a transaction’s input and verify with absolute certainty that it has never been used before.
Before Segregated Witness, the transaction structure looked like this:
(version) (input) (output) (lock time)
TXID is a hash of this data. The problem is that the ScriptSig (signature, hash preimage, etc.) that proves the transaction is valid is part of the input. You can also modify small program instructions within ScriptSig, without invalidating the cryptographic signature itself.
These “abuses” cause the TXID to change. This is a big problem for pre-signed transactions.
Lightning Network, Ark, Spark, BitVM, Discreet Log Contracts (DLC), these scaling tools all rely on pre-signed transactions. All transactions must be pre-signed to create unsigned funding transactions and ensure proper execution and safety of funds. in front Sign and confirm funding transactions. All of these systems use multi-signature authentication to ensure safety regarding double spending (this will be important later).
If that funding transaction is fraudulent and its transformation ID changes before it is confirmed in the block, all pre-signed transactions protecting the second-tier funds will be invalidated. None of these tools will work in an environment where anyone can change the funding TXID that propagates across the network.
Segregated Witness uses the undefined opcode as a kind of blinding curtain where ScriptSig was previously in the input, and moves all that data into a new transaction field called “witness.” The new transaction structure will look like this:
(version) (marker/flag) (input) (output) (monitoring) (lock time)
The input “blind curtain” allows old nodes to just mark everything behind them as valid by default, and new nodes to actually apply the appropriate validation logic. Legacy TXIDs no longer change due to changes in ScriptSig data within the monitor. This solved the problem of pre-signed transactions and opened the door to all scaling solutions being built today that use them.
However, a problem arises because the transaction Merkle tree in the block header only commits to the transaction’s traditional TXID. There is no commitment to sighting data within the block. This requires a watch commitment and watch transaction ID (WTXID). In much the same way that a regular Merkle tree of TXIDs is constructed, a tree of WTXIDs for each transaction is constructed and committed to coinbase transaction monitoring.
The only difference is that the root of the tree has been hashed with the reservation value and it is included in Coinbase monitoring. This allows you to use that value to commit to other new data fields in your consensus rules in the future. Before the invention of this Witness Tree Commitment (conceived by Luke Dashjr), it was assumed that a hard fork would be necessary for isolated witnesses due to changes in transaction structure and the need for separate witness commitments in block headers.
The “blind curtain” design also allows for arbitrary upgrades to the scripting system, as all new data is ignored and not validated by nodes that do not support it. This allows the new scripting system to avoid all the limitations of traditional scripting systems. The flexibility of the upgrade path here allows for the integration of Schnorr signatures, allowing for quantum-resistant signatures if desired (quantum-resistant public keys, like signatures, are typically larger than the traditional 520-byte data item limit).
Segregated Witness solved a fundamental problem with the malleability of transaction IDs that prevented the development of a scalable second layer that could bring Bitcoin to more users, but it also laid the foundation for the scripting improvements needed to support and improve those second layers.
Schnorr’s signature2
The Schnorr signature was invented by Claus Schnorr in 1991 and quickly patented. In fact, the ECDSA signature scheme was invented for a patent on Schnorr signatures. The patent on Schnorr signatures expired in February 2010, a little more than a year after the Bitcoin network was launched.
If it weren’t for the patent, Satoshi (and the rest of the world) might have been using Schnorr’s signature from the beginning.
Schnorr signatures have several significant advantages over ECDSA.
- Schnorr signatures have been proven to be secure. The mathematical proof that Schnorr signatures are unforgeable/unbreakable is much stronger and requires fewer assumptions than for ECDSA. Having stronger security guarantees for the cryptography at the heart of Bitcoin is clearly a huge benefit.
- Schnorr signatures are inherently inflexible. In other words, the ECDSA-type problems that can be changed without invalidating the signature are simply not possible with Schnorr signatures.
- The linear nature of Schnorr signatures allows simple and efficient construction of additional keys, generation of distributed keys, and generation of distributed signatures. This allows users to simply “add” individual Schnorr public keys and create signatures for their collective public keys as a group.
These are more secure, less susceptible to modification by third parties, and open the door to all kinds of efficient and flexible encryption schemes to improve multi-signature authentication.
Previously, when we talked about transaction malleability, we mentioned that anything that builds off-chain using pre-signed transactions relies on multi-signature authentication to protect users’ funds. This created an implicit scaling cap on shared management of funds. Traditional multisig is very large. There are transaction size limits, and for version 0 (separated monitors) monitors, there are monitor size limits. Since only a limited number of participants can participate in a multi-signature address, implicitly only a limited number of participants can share control of the funds.
Schnorr-based multisignature schemes get around this limitation by aggregating public keys into a single group public key, rather than building scripts that explicitly include each member key individually. Before Segregated Witness, a multi-signature address could only have 15 participants, but after Segregated Witness, the maximum possible participants was 20.
Use a Schnorr-based multi-signature scheme like MuSig5 and frost6 At least at the consensus level, these limitations do not exist. Multi-signature scripts can be as large as the user desires, as long as it is practical to coordinate the signing process within a group of the chosen size without interruption or denial of participation.
The same properties that enable such key aggregation also enable efficient adapter signing. This is a scheme that allows someone to create a signature that is invalid until the secret information is made public. These properties also enable schemes utilizing zero-knowledge proofs to create signatures on messages where the signer is invisible.
taproot3,4
Taproot is an evolution of an old concept called MAST (Merkelized Abstract Syntax Trees).7itself an extension of Pay-to-script-hash (P2SH).8. P2SH was originally created to address two major problems:
- Using large custom scripts results in larger unused outputs that require more space to store in the UTXO set.
- When using large custom scripts, senders pay more because they pay more for the transaction, which discourages people from paying for potentially more secure custom scripts.
Rather than explicitly including the entire script in the output, a hash of that script is included instead. Also, upon consumption, the receiver must provide the entire script in the input that is consumed to be verified against the hash. This solves the problem of unused output storage space and puts the cost of using large scripts on the person using the script, not on the person sending the funds.
This still leaves problems. A custom script can contain multiple usages, but at the time of usage the user must reveal the entire script, including script branches that are not needed to verify the conditions under which the coin is actually used. This is very space inefficient and costs the consumer more than necessary.
The idea behind MAST is to take the individual spending conditions in a multi-branch script, separate them, and build a Merkle tree of the individual spending paths. Each path is then hashed and the root of its Merkle tree becomes the user’s address. At the time of spending, users simply provide the spending path they are using, the Merkle proof that it is a leaf in the tree, and the data needed to satisfy that script.
This Merkle tree structure not only solves all the same problems as P2SH, but also optimizes spending costs (and improves privacy!) for MAST users.
Taproot takes this concept and integrates it in a more privacy-preserving way by leveraging the linear properties of Schnorr signatures. Most types of contracts that people want to structure will have an optimistic outcome where both users simply agree on how to distribute the funds. In such cases, all you need to do is sign the transaction. Taproot takes the MAST root, “tweaks” the Schnorr public key, and generates a new public key. If you use the same MAST route to “tweak” your private key, you’ll get a private key that corresponds to your new public key.
Users can either use the output with the adjusted keys without leaving any trace of the existence of the MAST tree, or they can reveal the original public key and MAST root along with the actual usage paths. Alternatively, if you don’t want to include a key path, you can use a special NUMS (Nothing Up My Sleeve) value that is known not to be usable in place of the regular public key, leaving the MAST script as the only valid usage path.
Taproot also leveraged Segregated Witness’ design choices to introduce a new scripting system, Tapscript. The main change here is to deactivate OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. These have been replaced by OP_CHECKSIGADD, which allows multiple signatures to be verified more efficiently. This combined with Schnorr key aggregation allows for the same multi-signature functionality as legacy scripts.
Tapscript also modifies OP_CHECKSIG and OP_CHECKSIGVERIFY to work only with Schnorr signatures, and introduces OP_SUCESS instead of OP_NOP (an undefined opcode in legacy scripts). OP_SUCCESS is designed to allow for cleaner and safer opcode upgrades than OP_NOP.
limits of witness
Until now, two aspects have been left undiscussed. Block weight limits introduced in Segregated Witness and increased witness size limits in Taproot.
Each of these decisions is a point of contention among a small number of very active power users in the ecosystem. We do not discuss the increase in block size that is part of the introduction of block weight limits. This was a compromise at the time with opposing users pushing for increased block sizes through hard forks, and was considered safe by network participants at the time. However, the mechanism of the witness discount itself is important.
Bitcoin transaction fees are calculated based on the amount of data in the transaction. This has nothing to do with the amount of value transferred. It’s just the number of inputs and outputs (and monitors) and the number of bytes of data on them. Remember earlier that I mentioned the fact that before Segregated Witness, transaction inputs included ScriptSigs, signatures and other data. This is a large amount of data that is included in the input but not included in the output.
In other words, Input costs more than output In trading, it’s a big difference. This creates a long-term incentive for users to prefer spending large outputs to create new changes rather than collecting and consuming large amounts of small outputs. This is a long-term economic incentive that encourages users to permanently expand the UTXO set required for all fully validating nodes.
Witness discounts are intended to fix price margins and will be negligible rather than massive. This is very important to economically incentivize responsible UTXO management, at least for users who are financially rational enough to trade.
Taproot has removed the existing size limit for transaction monitoring fields. For Segregated Witness, that limit was 10,000 bytes. This is because Taproot’s design reduces the possibility of constructing transactions that are expensive to verify, and attempting to introduce such restrictions in Tapscript would significantly complicate Miniscript. The issues that existed to prevent such restrictions did not affect Taproot and introduced complexity to a tool aimed at making custom scripts safer and more accessible for both developers and users.
big picture
Both of these changes to Bitcoin have been removed large scale While there are some obstacles to scaling it for use by more people in a self-custodial manner, the fundamentals of the protocol required extensive changes as well.
We hope that readers who may not have previously been familiar with these design choices and the rationale behind them now understand that they are carefully and forward-thinking. Bitcoin is an amazing innovation, and it certainly is, but it doesn’t bring its benefits to close to a significant percentage of the population.
Segregated Witness and Taproot have built on two fundamentals that are absolutely necessary to address Bitcoin’s scalability shortcomings. Without these two proposals, or alternative protocol changes that addressed the same issues, we would not have all the growing scalability layers and systems we have today.
Lightning, Ark, Spark, BitVM, DLC – you can’t build any of them.
That’s the big picture. Bitcoin today is not perfect, but it actually has a good chance of making a real impact on the world and expanding to groups of people meaningful enough to provide a real alternative for those considering opting out. That’s because of the upgrades to these two protocols and the very basic barriers they remove.
Get “The Core Issue” now!
Don’t miss your chance to get it core issue — Features articles written by many core developers describing the projects they work on.
This article is a letter from the editor published in the latest print edition of Bitcoin Magazine, the Core issue. I’m sharing it here as an early look at the ideas explored throughout the issue.
(1) https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
(2) https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
(3) https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
(4) https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
(5) https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki
(6) https://github.com/siv2r/bip-frost-signing
(7) https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki
(8) https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki
This article, “The Core Question: Why Bitcoin Needs a Segwit and Taproot Mod” was first published in Bitcoin Magazine and was written by Shinobi.
