{"id":18805,"date":"2020-01-06T13:00:38","date_gmt":"2020-01-06T13:00:38","guid":{"rendered":"http:\/\/ci027cfe6530012697"},"modified":"2025-10-02T15:07:26","modified_gmt":"2025-10-02T20:07:26","slug":"2020-and-beyond-bitcoins-potential-protocol-upgrades","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/2020-and-beyond-bitcoins-potential-protocol-upgrades","title":{"rendered":"2020 and Beyond: Bitcoin\u2019s Potential Protocol Upgrades"},"content":{"rendered":"
<\/div>
<\/figure>\n

Bitcoin\u2019s consensus layer has remained unchanged for over two years now. Since Segregated Witness (SegWit), which activated in August 2017, no hard fork or soft fork protocol upgrades have been deployed at all*, marking Bitcoin\u2019s longest stretch without consensus forks so far.<\/p>\n

But this stretch may soon come to an end: several backward-compatible soft forks are currently in development. Optimistically, some of them may go live in 2020 \u2014 if they gather sufficient support from the Bitcoin ecosystem.<\/p>\n

These could be Bitcoin\u2019s protocol upgrades in the new year \u2026 or perhaps in the new decennium.<\/p>\n

Schnorr\/Taproot\/Tapscript<\/h2>\n

Schnorr signatures are considered by many cryptographers to be the best type of cryptographic signatures in the field. They offer a strong level of correctness, do not suffer from malleability, are relatively fast to verify and, perhaps most interestingly, allow for math to be performed with them. To name one concrete benefit for Bitcoin: Several signatures can be aggregated into a single signature, which could, for example, economically incentivize privacy-enhancing CoinJoin transactions<\/a>.<\/p>\n

Adding Schnorr signatures to the Bitcoin protocol has been a work in progress for some time now. But over the past year, developers working on a Schnorr signatures<\/a> proposal, like Blockstream developers Pieter Wuille and Jonas Nick and Xapo’s Anthony Towns, revealed even more ambitious plans. Schnorr signatures will be proposed as part of a bigger soft fork protocol upgrade called Taproot<\/a>, a proposal by Bitcoin Core contributor Gregory Maxwell, which was itself inspired by an older proposal called MAST<\/a> (Merkelized Abstract Syntax Tree).<\/p>\n

(Fractions of) bitcoin can be locked up in such a way that they can be spent under several different conditions, for example requiring timelocks, secret numbers of several participants to agree to unlock the coins. With MAST, all the different conditions are hashed and included in a Merkle Tree: a compact cryptographic data structure. The coins would then essentially be locked up in the final hash of this Merkle Tree, the Merkle Root. To spend the coins, you only <\/em>need to reveal the condition you end up using. The alternative ways in which the coins could have been unlocked remain hidden forever.<\/p>\n

Taproot, then, is based on an interesting realization: No matter how complex, almost any MAST-construction could (or should) include a condition that allows all participants to agree on the outcome and sign off on a settlement transaction together. This \u201ccooperative close\u201d would override all other conditions.<\/p>\n

Taproot leverages this realization and utilizes Schnorr signatures to make the cooperative close look like a regular transaction. Simplified, the cooperative close would be done with an aggregated signature, which looks just like a regular signature. In doing so, the MAST-construction remains completely hidden to the outside world! This benefits privacy and efficiency.<\/p>\n

Taproot may also come with an updated version of Bitcoin\u2019s programming language, Script, called Tapscript<\/a>. This would also make it easier to add new features (\u201cOP codes\u201d) to Bitcoin\u2019s programming language later on.<\/p>\n

Taproot doesn\u2019t appear to be very contentious, though developers are still discussing implementation details.<\/p>\n

For further reading, see <\/em>this article<\/em><\/a> and <\/em>this article<\/em><\/a>.<\/em><\/p>\n

The Great Consensus Cleanup<\/h2>\n

The Great Consensus Cleanup<\/a> is a proposed soft fork by Square Crypto developer Matt Corallo. As opposed to most protocol upgrades \u2014 including the other upgrades included in this list \u2014 The Great Consensus Cleanup is not intended to enrich Bitcoin with new features or possibilities. Instead, as the name suggests, this soft fork would remove some edge case vulnerabilities from the Bitcoin protocol.<\/p>\n

These vulnerabilities are quite technical and \u201cin the weeds.\u201d They include, for example, fringe types of transactions that require much processing power to validate, redundant tricks for upgrading parts of the protocol, and a weak spot in Bitcoin\u2019s difficulty adjustment algorithm. It has been known for some time that these vulnerabilities existed, but it is generally believed that exploiting them would be too costly to be profitable, or that such exploits would be relatively easy to deal with when they happen. Still, fixing them would make Bitcoin slightly more robust, while it would make developing Bitcoin implementations a bit easier.<\/p>\n

The main objection to (parts of) The Great Consensus Cleanup is probably that some of the upgrades could, in theory, make certain existing coins (UTXOs) unspendable. While it\u2019s very unlikely that such UTXOs exist at all, it is impossible to know for sure whether they do, and some argue that making them unspendable is a risk that should, as a matter of principle, never be taken.<\/p>\n

For further reading, see the BIP, the <\/em>Bitcoin-dev mailing list discussion<\/em><\/a> and<\/em> Bitcoin Optech Newsletter #36<\/em><\/a>.<\/em><\/p>\n

The \u201cNoinput Class\u201d<\/h2>\n

Bitcoin transactions include cryptographic signatures, which prove that the owner of a public key really wants to spend the corresponding coins in that specific transaction. But not the whole transaction is signed. Which part of a transaction is signed exactly is indicated with something called a \u201csighash flag.\u201d<\/p>\n

Now, a new class of sighash flags is being proposed by Blockstream developer Christian Decker and Xapo\u2019s Towns. Carrying names like SIGHASH_NOINPUT<\/a>, SIGHASH_ANYPREVOUT<\/a> and SIGHASH_ANYPREVOUTANYSCRIPT, they offer a similar solution, so we\u2019ll refer to all of these as the \u201cNoinput class.\u201d<\/p>\n

If a sighash flag in the Noinput class is included in a transaction, it indicates that the outputs (the \u201creceiving\u201d part of the transaction) and some other transaction data will be signed, but not<\/em> the inputs (the \u201csending\u201d part of the transaction). By not signing the input, it is possible to take a transaction even after it is signed and swap in a different but compatible input. <\/p>\n

More often than not, there wouldn\u2019t be any other compatible input. The signature still corresponds to a public key, and this public key corresponds only to a specific (fraction of a) coin. Swapping in a random input would break this link and make the transaction invalid.<\/p>\n

But there are some exceptions where the input can be swapped. Notably, Bitcoin transactions for a new type of Lightning Network payment channel protocol, called Eltoo, could be subject to having their input swapped for a compatible input. This would significantly simplify how payment channels are enforced. Most notably, bugs and other honest mistakes wouldn\u2019t lead to a loss of all funds in a channel, and users could do with far less backup data.<\/p>\n

The main objection to the Noinput class is that SIGHASH_NOINPUT in particular can be insecure if used improperly. SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT resolve this (and make it compatible with Taproot), but at the cost of more complexity. Some also suggest that OP_CHECKTEMPLATEVERIFY (see below) or OP_cat<\/a> (a disabled OP code that could be re-enabled, perhaps through Tapscript) could offer similar benefits.<\/p>\n

For further reading, see<\/em><\/em>this article<\/em><\/a>.<\/em><\/p>\n

OP_CHECKTEMPLATEVERIFY<\/h2>\n

OP_CHECKTEMPLATEVERIFY<\/a> (CTV), previously known as OP_SECURETHEBAG, is a new OP code proposed by Bitcoin Core contributor Jeremy Rubin. As its main benefit, it could help smooth out Bitcoin\u2019s network congestion and fees during peak hours, effectively increasing network throughput.<\/p>\n

More specifically, CTV would, in a way, allow a Bitcoin transaction to be cut into two transactions. The \u201csending\u201d half of the transaction would include the inputs, basically the addresses the coins are sent from<\/em>. The \u201creceiving\u201d part of the transaction includes the outputs, basically the addresses the coins are sent to<\/em>.<\/p>\n

The two halves would be tied to each other through a special output included in the \u201csending\u201d transaction, called a \u201ccommitted output.\u201d The committed output would contain a cryptographic hash: a seemingly random but relatively short string of numbers that serves as a unique serial number, linking it to the \u201creceiving\u201d transaction. The coins that are \u201csent\u201d in the \u201csending\u201d transaction can only be \u201creceived\u201d by the \u201creceiving\u201d transaction.<\/p>\n

The trick is that both \u201chalves\u201d \u2014 the \u201csending\u201d and the \u201creceiving\u201d transaction \u2014 are broadcast to the network, with an important difference. The \u201csending\u201d transaction includes a relatively large fee to ensure that it confirms fast. The \u201creceiving\u201d transaction includes a relatively low fee, meaning it could take a while to confirm.<\/p>\n

The wait for the low-fee transaction to confirm shouldn\u2019t be a big deal for the recipients of the coins. Once the \u201csending\u201d transaction is confirmed, it ensures that all the money is guaranteed to the \u201creceiving\u201d transaction. The funds are anchored in the blockchain and have nowhere else to go but to the recipients.<\/p>\n

If recipients do need to speed up the \u201creceiving\u201d transaction, for example, because they have to re-spend the coins, they can simply spend their funds straight from the unconfirmed \u201creceiving\u201d transaction. If the fee on the new transaction is high enough to compensate, both the \u201creceiving\u201d transaction and the new transaction will be confirmed quickly. (This trick is called \u201cChild Pays for Parent.\u201d) Even more interesting, CTV allows for more efficient solutions by chopping the \u201creceiving\u201d transaction into smaller transactions, called Tree Payments.<\/p>\n

The main objection to CTV is probably that there may be better and\/or more general ways to accomplish the same thing. (The more general solution is usually referred to as Covenants<\/a>.) Some also suggest that the Noinput class or OP_cat<\/a> could offer similar benefits.<\/p>\n

For further reading, see<\/em><\/em>this article<\/em><\/a>.<\/em><\/p>\n

Drivechain BIPs<\/h2>\n

Sidechains are blockchains that are \u201cpegged\u201d to the Bitcoin blockchain, allowing bitcoin to effectively \u201cmove\u201d from Bitcoin\u2019s blockchain to the sidechain and back. Once the coins are on the sidechain, they would obey the protocol rules of that blockchain, which could be about as diverse as any blockchain in existence today. There could, for example, be a \u201cZcash sidechain\u201d for privacy, an \u201cEthereum sidechain\u201d for certain smart contracts or a \u201cbig block sidechain\u201d for low-fee blockchain transactions.<\/p>\n

Some sidechains already exist, most notably Blockstream\u2019s Liquid (primarily for inter-exchange fund transfers) and RSK Labs\u2019 RSK (an \u201cEthereum sidechain\u201d). These are \u201cfederated sidechains\u201d: the bridge between Bitcoin\u2019s blockchain and the sidechain is managed by a \u201cfederation\u201d of well-known companies in the space. They essentially control a multisignature address on the Bitcoin blockchain and collectively sign to \u201cmove\u201d coins back and forth.<\/p>\n

Drivechains would instead be secured by bitcoin miners: The same miners providing the hashpower that already secures the Bitcoin blockchain. \u201cMoving\u201d funds from the sidechain back to the main chain would require a majority of hash power over an extended period of time. Further, drivechains would be merged mined, meaning that hash power on the Bitcoin blockchain also protects the sidechain.<\/p>\n

To realize this, Tierion developer Paul Sztorc and the pseudonymous CryptAxe have proposed two soft forks. The first one, called Hashrate Escrows<\/a>, would act to lock funds in a contract on Bitcoin\u2019s blockchain (\u201cmoving\u201d them to the sidechain), to only be unlocked once sufficient hash rate votes to unlock the funds (\u201cmoving\u201d the coins back). The second soft fork, called Blind Merged Mining<\/a>, would enable the sidechain to be secured by the same hashpower as the Bitcoin blockchain.<\/p>\n

Drivechains are somewhat controversial, because (it is argued that) it would give more power to bitcoin miners. Some also suggest<\/a> that blind merged mining could be achieved with the Noinput class.<\/p>\n

For further reading, see<\/em><\/em>drivechain.info<\/em><\/a> and the<\/em><\/em>Bitcoin-dev mailing list discussion<\/em><\/a>.<\/em>*Depending on your definition of \u201chard fork\u201d and \u201csoft fork,\u201d it could be argued that the<\/em><\/em>inflation bug<\/em><\/a>, included in Bitcoin Core versions in 2017 and 2018, was fixed with a soft fork in 2018. But even if considered a soft fork, which is dubious, this can hardly be considered a protocol upgrade.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

The end of Bitcoin\u2019s longest stretch without consensus forks?<\/p>\n","protected":false},"author":2509,"featured_media":18806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[1173,1141,1075],"class_list":["post-18805","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technical","tag-drivechains","tag-schnorr","tag-taproot"],"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/bitcoins-potential-2020-protocol-upgrades.jpg","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/18805","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=18805"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/18805\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/18806"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=18805"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=18805"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=18805"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}