Bitcoin Magazine The Core Issue: Why Bitcoin Needed A Remodel With Segwit and Taproot Segregated Witness (BIP by Pieter Wuile, Eric Lombrozo, and Johnson Lau) and Taproot (BIPs by Pieter Wuille, Jonas Nick, Tim Ruffing, and Anthony Towns) are the two largest changes ever made to the Bitcoin protocol. The former fundamentally changed the structure of Bitcoin transactions, and in the process Bitcoin blocks, to address inherent limitations of the previous transaction structure. The latter rearchitectured some aspects of Bitcoin’s scripting language, how complex scripts are structured and validated, and introduced a new scheme for creating cryptographic signatures. Those are both massive changes in comparison to say, adding a single opcode like CHECKTIMELOCKVERIFY (CLTV) that does nothing more than allow the receiver to opt into preventing their coins from moving for a certain amount of time. These changes were made to address very real shortcomings and limitations of Bitcoin as a system. As a foundational layer to maintain a global consensus on the overall state of Bitcoin, i.e all the unspent coins, Bitcoin is an invaluable and brilliant innovation. As a means to directly enable everyone to transact with those coins, it is woefully inadequate to the task. In the years since Segregated Witness and Taproot activated, many of the shortcomings they addressed have been forgotten. The reasons and rationale behind the design decisions have been distorted in a game of telephone as time passed as well. Both of these changes to the Bitcoin protocol were solutions to large problems in their own right, but they also each laid the groundwork for solving other problems or making other improvements in the future. At a time where many new people have joined the network since these changes activated, it is worth going back over and contextualizing the design choices. Segregated Witness (BIP 1411) When a Bitcoin transaction spends coins, it references them by the output index and transaction ID (TXID) of the transaction that created them. This ensures that a transaction’s inputs can be uniquely identified and be verified with absolute certainty to have never been spent before. Prior to Segregated Witness, a transaction structure looked like this: [Version] [Inputs] [Outputs] [Locktime] The TXID is a hash of this data. The problem is the ScriptSig (the signatures, hash preimages, etc.) that prove the transaction is valid are part of the inputs. You can change the little program instructions in a ScriptSig, or even change the cryptographic signatures themselves without invalidating them. These “malleations” change TXIDs. This is a big problem for pre-signed transactions. The Lightning Network, Ark, Spark, BitVM, Discreet Log Contracts (DLCs), all of these scaling tools depend on pre-signed transactions. They require creating an unsigned funding transaction, and pre-signing all the transactions that guarantee proper execution and safety of funds before signing and confirming the funding transaction. All of these systems use multisignature authentication to guarantee safety regarding double-spending (this will be important later). If that funding transaction is malleated, and its translation ID changed before it is confirmed in a block, then all of the pre-signed transactions securing second layer funds are invalidated. None of these tools work in an environment where anyone can alter your funding TXID as it propagates across the network. Segregated Witness uses an undefined opcode as a sort of blinding curtain where the ScriptSig previously was in the inputs, and moves all of that data to a new transaction field called the “witness.” The new transaction structure looks like this: [Version] [Marker/Flag] [Inputs] [Outputs] [Witness] [Locktime] The “blinding curtain” in the inputs allows old nodes to just mark everything behind it as valid by default, and newer nodes to actually apply the appropriate validation logic. A traditional TXID will now no longer change due to altering ScriptSig data in the witness. This solved the problem for pre-signed transactions, and opened the door to every scaling solution being built today that uses them. But the transaction merkle tree in a block header only commits to the traditional TXID of a transaction, this creates a problem. There is no commitment to any witness data in a block. This requires the witness commitment, and the witness transaction ID (WTXID). Much the same way that the normal merkle tree of TXIDs is constructed, a tree of each transaction’s WTXID is constructed and committed to in the coinbase transaction’s witness. The only difference is the root of the tree is hashed with a reserve value, and that is what is included in the coinbase witness. This allows for that value to be used in future for committing to other new data fields in consensus rules. Prior to the invention of this witness tree commitment (which was thought of by Luke Dashjr), it was assumed Segregated Witness would require a hardfork due to the transaction structure change and the need for a separate witness commitment in the block header. The “blinding curtain” design also allows arbitrary upgrades to the scripting system because all new data is ignored and not validated by nodes not supporting it. This allows a new script system to bypass all restrictions of the legacy script system. Flexibility in upgrade paths here is what allowed Schnorr signatures to be integrated, and will allow quantum resistant signatures if necessary (quantum resistant public keys are generally larger than the legacy 520-byte data item limit, as are signatures). Segregated Witness solved the fundamental problem of transaction ID malleability that was holding back the development of scalable second layers that can bring Bitcoin to more users, but it also laid the groundwork for whatever scripting improvements were necessary to support and improve those second layers. Schnorr Signatures2 Schnorr signatures were invented in 1991 by Claus Schnorr, and promptly patented. In fact, the ECDSA signature scheme was invented because of the patent on Schnorr signatures. The patent on Schnorr signatures expired in February 2010, a little more than a year after the launch of the Bitcoin network. If it weren’t for the patent, it is likely that Satoshi (and the rest of the world) would have just used Schnorr signatures from the start. There are a few major benefits that Schnorr signatures have over ECDSA: Schnorr signatures are provably secure. The mathematical proof that Schnorr signatures are unforgeable/unbreakable is much stronger, and makes less assumptions, than that for ECDSA. Having stronger security guarantees for the cryptography that rests at the heart of Bitcoin is obviously a huge positive. Schnorr signatures are inherently non-malleable, meaning that the types of issues with ECDSA that allowed altering a signature without invalidating it are simply not possible with Schnorr signatures. Schnorr signatures have a linearity that allows for simple and efficient additive key construction, distributed key generation, and distributed signature generation. This allows users to simply “add” individual Schnorr public keys together, and produce signatures for those aggregate public keys together as a group. They’re more secure, not malleable by third parties, and open the door to all kinds of efficient and flexible cryptographic schemes to improve multisignature authentication. Earlier when discussing transaction malleability I mentioned that everything building off-chain using pre-signed transactions depended on multisignature authentication to secure user funds. This created an implicit scaling ceiling when it comes to shared control of funds. Legacy multisig can only be so big. There are transaction size limits, and for version 0 (Segregated Witness) witnesses, there is a witness size limit. Only so many participants could join a multisignature address, so implicitly only so many participants could share control of funds. Schnorr based multisignature schemes escape this limit by aggregating public keys into a single group public key rather than constructing a script with each member key explicitly included individually. Prior to Segregated Witness a multisignature address could only have 15 participants, after Segregated Witness the maximum size possible was 20 participants. With Schnorr based multisignature schemes like MuSig5 and FROST6 these limitations don’t exist, at least at the consensus level. Multisignature scripts can be as large as users want as long as it is practical to coordinate the signing process within a group of the chosen size without disruption or refusal to participate. The same properties that allow key aggregation like this also allow for efficient adaptor signatures, a scheme that allows someone to produce a signature that remains invalid until after a secret piece of information is revealed. Those properties also allow for a zero-knowledge proof powered scheme for a signer to produce a signature over a message they cannot see. Taproot3,4 Taproot is an evolution of an old concept called Merkelized Abstract Syntax Trees (MAST)7, which is itself a kind of extension of Pay-to-script-hash (P2SH)8. P2SH was originally created to deal with two major problems: When using large custom scripts, the resulting unspent output is larger, requiring more space to store in the UTXO set. When using large custom scripts, the sender pays a higher fee, as the payment output in their transaction is larger, thereby disincentivizing people from paying potentially more secure custom scripts. Rather than explicitly include the entire script in the output, a hash of that script is included instead, and at spending time the recipient must provide the entire script in the input being spent to be verified against the hash. This solved the problem of unspent output storage space, and puts the cost of using larger scripts on the person using them rather than those sending them funds. This still leaves a problem. Custom scripts can include multiple ways to spend them, but at spending time the user must still reveal the entirety of the script, including script branches that are not necessary to verify the condition under which the coin is actually spent. This is incredibly space inefficient, and leaves the spending user with a higher cost than is necessary. The idea behind MAST is to take each individual spending condition in a multi-branch script and separate them, constructing a merkle tree of each individual spending path. Each path is then hashed, and the root of that merkle tree is the user’s address. At spending time the user simply provides the spending path they are using along with the merkle proof that it is a leaf in the tree, along with the data necessary to satisfy that script. This merkle tree structure solves all the same problems as P2SH, as well as optimizing the spending costs of the MAST user (and improves their privacy as well!). Taproot takes this concept and integrates in a more privacy-preserving way by taking advantage of the linear properties of Schnorr signatures. Most types of contracts people want to build are going to have an optimistic outcome, where both users simply agree on how to disperse funds. In such cases they can just sign a transaction. Taproot takes the MAST root and “tweaks” a Schnorr public key, resulting in a new public key. By “tweaking” the private key with the same MAST root, you arrive at the corresponding private key to the new public key. Users can now either simply spend an output using that tweaked key, leaving no trace that a MAST tree is present at all, or reveal the original public key and MAST root along with the spending path they are actually using. As well, if you wish to not include a key path, a special NUMS (Nothing Up My Sleeve) value which is provably unspendable can be used instead of a normal public key, leaving only MAST scripts as valid spending paths. Taking advantage of the design choices of Segregated Witness, Taproot also introduced tapscript, a new scripting system. The major changes here are deactivating OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. They are replaced with OP_CHECKSIGADD, which allows a more efficient way to verify multiple signatures. This in combination with Schnorr key aggregation allows the same multisignature functionality as legacy script. Tapscript additionally modifies OP_CHECKSIG and OP_CHECKSIGVERIFY to only work with Schnorr signatures, and introduces OP_SUCESS as a replacement for OP_NOP (undefined opcodes in legacy script). OP_SUCCESS is designed to allow cleaner and safer opcode upgrades than OP_NOP. Witness Limits Two aspects have been left undiscussed until now. The blockweight limit introduced in Segregated Witness, and the witness size limit increase in Taproot. Both of these decisions have become a point of contention among a very active minority of power users in the ecosystem. I won’t be discussing the blocksize increase that was part of introducing the blockweight limit, this was a compromise at the time with dissenting users pushing for a hardfork blocksize increase and deemed safe by network participants at the time; but the dynamic of the witness discount itself is important. Bitcoin transaction fees are based on the amount of data in a transaction. This has no relationship to the amount of value being transferred. It is solely the number of inputs and outputs (and witnesses) and how many bytes of data they are. Recall earlier I mentioned the fact that the ScriptSig, or signatures and other data, were included in the transaction inputs prior to Segregated Witness. This is a large amount of data included in inputs that is not included in outputs. That means inputs are more expensive than outputs in a transaction, and by a wide margin. This creates a long term incentive for users to also prefer spending large outputs and creating new change ones as opposed to collecting and spending lots of smaller outputs. This is a long term economic incentive encouraging users to perpetually grow the UTXO set which is necessary for all fully validating nodes. The witness discount is meant to correct that price margin, making it miniscule as opposed to massive. This is incredibly important to economically incentivize responsible UTXO management, at least in vacuum for economically rational users simply transacting. Taproot removed existing size limits on the witness field of a transaction. In Segregated Witness that limit was 10,000 bytes. This was done because the design of Taproot mitigated the potential construction of expensive to verify transactions, and trying to introduce such limits in tapscript introduced a large degree of complexity in Miniscript. The problem such limits existed to prevent did not impact Taproot, and it introduced complexity for a tool meant to make custom scripts safer and more accessible for both developers and users. The Big Picture Both of these changes to Bitcoin removed massive roadblocks to scaling it so more people can use it in a self-custodial way, but they necessitated similarly massive changes to fundamental parts of the protocol. I hope now that readers previously unfamiliar with all of these design choices, and the rationale behind them, can appreciate the care and forward-thought with which they were designed. Bitcoin is an amazing innovation, it truly is, but it cannot provide its benefits to anything remotely approaching a sizeable percentage of the population. Segregated Witness and Taproot laid two cornerstones in the foundation that were absolutely necessary in order to attempt to address Bitcoin’s scalability shortcomings. Without these two proposals, or some alternative protocol changes that addressed the same problems, all of these growing scalability layers and systems we have today would not be here. Lightning, Ark, Spark, BitVM, DLCs – none of them would be possible to build. That is the big picture. The Bitcoin of today isn’t perfect, but it actually stands a good chance of scaling to a meaningful enough group of people to make a real impact on the world, to offer a true alternative to people looking to opt out. That is because of these two protocol upgrades, and the very fundamental barriers they removed. Get your copy of The Core Issue today! Don’t miss your chance to own The Core Issue — featuring articles written by many Core Developers explaining the projects they work on themselves! This piece is the Letter from the Editor featured in the latest Print edition of Bitcoin Magazine, The Core Issue. We’re sharing it here as an early look at the ideas explored throughout the full 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 post The Core Issue: Why Bitcoin Needed A Remodel With Segwit and Taproot first appeared on Bitcoin Magazine and is written by Shinobi.
