The Bitcoin consensus layer has not changed for two years, and these upgrades may be available this year

For more than two years, Bitcoin's consensus layer has remained unchanged. Since the launch of SegWit in August 2017, Bitcoin has not undergone a hard fork or soft fork protocol upgrade. This is the longest period of time that Bitcoin has maintained a consensus-free fork.

However, this state may end soon: several backward-compatible soft forks are currently under development. Optimistically, if they can get enough support from the Bitcoin ecosystem, some of them may be activated in 2020.

This article lists those protocol upgrades that could be Bitcoin in the new year … or in the new decade.

• In 2019, I was on the spot | 15 of the "most" found from 736 articles, which one do you like best?
• After the Ethereum Muir Glacier hard fork upgrade, the block time interval dropped by 25%
• Xinhua Finance Inventory: Ten Major Events of the Blockchain Industry in 2019

Schnorr / Taproot / Tapscript

Many cryptographers consider Schnorr signatures to be the best type of cryptographic signature in the field. They provide strong accuracy, are not affected by malleability, are relatively fast to verify, and perhaps most interestingly, can perform mathematical operations. For Bitcoin, one of the advantages is that several signatures can be aggregated into one signature. For example, this can economically stimulate CoinJoin transactions that enhance privacy.

The plan to include Schnorr signatures in the Bitcoin protocol has been going on for some time. But in the past year, developers working on Schnorr signature schemes, such as Blockstream developers Pieter Wuille, Jonas Nick and Xapo's Anthony Towns, have revealed more ambitious plans. The Schnorr signature will become part of Taproot, a soft fork protocol upgrade. This is a protocol upgrade proposed by Bitcoin Core contributor Gregory Maxwell. It itself is inspired by an older scheme called MAST (Merkelized Abstract Syntax Tree).

Bitcoins can be locked and can only be used under a few different conditions, such as requiring timelocks, which require a secret number provided by several participants to unlock these Bitcoins. With MAST, various conditions are hashed and included in the Merkle Tree: a compact encrypted data structure. These coins are locked in the last hash of the Merkel tree, which is Merkle Root. To spend these coins, you just need to inform you of your final use. Other ways that these coins may be unlocked will always be hidden.

Taproot is based on an interesting deployment: no matter how complicated, almost any MAST structure can (or should) include a condition that allows all participants to agree on the result and sign a settlement transaction together. This "collaborative settlement" will cover all other conditions.

Taproot uses this deployment and uses Schnorr signatures to make collaborative settlement look like a regular transaction. In simple terms, collaborative settlement will be done using an aggregate signature, which looks like a normal signature. In this process, the MAST structure is completely closed to the outside world! This benefits privacy and efficiency.

Taproot may also come with an upgraded version of the Bitcoin programming language Tapscript, and it will become easier to add new features ("opcodes") to the Bitcoin programming language in the future.

Although developers are still discussing deployment details, Taproot doesn't seem to be much controversial.

"Big Consensus Cleanup"

The Great Consensus Cleanup is a soft fork proposed by Square Crypto developer Matt Corallo. Unlike most protocol upgrades (including other upgrades listed in this article), the "Big Consensus Cleanup" does not intend to enrich Bitcoin with new features or new possibilities. Instead, as its name implies, this soft fork will remove some edge-case vulnerabilities in the Bitcoin protocol.

These vulnerabilities are highly technical and "overgrown." Examples include edge transaction types that require a lot of processing power to verify, redundant techniques for upgrading some protocols, and a weakness in the Bitcoin difficulty adjustment algorithm. These vulnerabilities have been known for some time, but it is generally believed that exploiting them is too costly and unprofitable, or it is relatively easy to deal with when these vulnerabilities occur. However, fixing these vulnerabilities will make Bitcoin more robust, and it will also make Bitcoin development easier.

The main reason for opposing the "great consensus cleanup" may be that, theoretically, certain upgrades may render certain existing coins (UTXOs) unusable. Although such UTXOs are impossible to exist at all, it is impossible to know for sure whether they exist. Some people think that making these coins impossible to spend is a risk, and in principle, this risk should never be taken.

"Noinput category"

Bitcoin transactions include cryptographic signatures to prove that the owner of the public key really wants to use the corresponding Bitcoin in a particular transaction. But not the entire transaction is signed, and which part of the transaction is signed is indicated by something called a "sighash sign."

Blockstream developers Christian Decker and Xapo's Towns have proposed a new class of sighash logos, including SIGHASH_NOINPUT, SIGHASH_ANYPREVOUT, and SIGHASH_ANYPREVOUTANYSCRIPT, which provide similar solutions, so we call them all "Noinput categories".

If the sighash flag in the Noinput category is included in a transaction, it means that the output ("receive" part of the transaction) and some other transaction data will be signed, but not the input ("send" part of the transaction). If you do not sign the input, you can switch to a different but compatible input, even after you sign the transaction.

Normally, there are no other compatible inputs. The signature still corresponds to a public key, and this public key only corresponds to a specific coin (or part). Switching to random input will break such connections and invalidate transactions.

But there are some exceptions where the input can be exchanged. It is worth noting that a new type of Lightning Network payment channel protocol called Eltoo for Bitcoin transactions may need to exchange their input for another compatible input. This will greatly simplify the way payment channels are implemented. Most notably, loopholes and other honest mistakes will not result in the loss of all funds for a channel, and users can use fewer backup data.

The main disadvantage of the Noinput category is that SIGHASH_NOINPUT, especially if used improperly, can be unsafe. SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT solve this problem (and make it compatible with Taproot), but at the cost of increased complexity. Some people have also suggested that OP_CHECKTEMPLATEVERIFY (see below) or OP_cat (which can re-enable disabled opcodes via Tapscript) can achieve similar goals.

OP_CHECKTEMPLATEVERIFY

OP_CHECKTEMPLATEVERIFY (CTV), once called OP_SECURETHEBAG, is a new opcode proposed by Bitcoin Core contributor Jeremy Rubin. Its main advantage is that it can help alleviate Bitcoin network congestion and expenses during peak hours, and effectively improve network throughput.

More specifically, CTV will to some extent split a Bitcoin transaction into two. The "send" part of the transaction will include the input, which is basically the source address of the coin. The "receiving" part of the transaction includes the output, which is basically the address to which the coin was sent.

The two parts are bound to each other through the special output of the "committed output" contained in the "send" transaction. The submission output will contain a cryptographic hash: a seemingly random but relatively short number of short characters that serves as a unique serial number that links it to the "receiving" transaction. Coins that are "sent" in a "send" transaction can only be "received" by a "receive" transaction.

The point is that both the "send" and "receive" transactions are broadcast to the network. There are important differences between the two. The "send" transaction includes a relatively large fee to ensure fast confirmation. "Receiving" transactions include relatively low fees, which means it may take some time to confirm.

Waiting for confirmation of a low-fee transaction should not be a big deal for the recipient of the transaction. Once the "send" transaction is confirmed, it will ensure that all money goes to the "receive" transaction. These funds are fixed in the blockchain and cannot be used for any purpose other than being issued to recipients.

If the recipient does need to speed up the "receiving" transaction, for example, because they have to re-spend the coins, they can spend the funds directly from the unconfirmed "receiving" transaction. If the cost of the new transaction is high enough, both the "receiving" transaction and the new transaction will be confirmed quickly. More interestingly, CTV can split "receiving" transactions into smaller transactions, called Tree Payments, to improve efficiency.

The main argument against CTV may be that there may be better or simpler ways to accomplish the same goal. Some people also think that the Noinput category or OP_cat can do it.

Drive chain BIP

The sidechain is a blockchain that is "anchored" on the Bitcoin blockchain, allowing Bitcoin to effectively move back and forth between the Bitcoin blockchain and the sidechain. Once coins are on the sidechain, they will follow the protocol rules of the sidechain. For example, we can set up a “Zcash side chain” containing privacy functions, an “Ethereum side chain” containing smart contracts, or a “big block side chain” of a low-cost blockchain.

There are already some sidechains, the most well-known are Blockstream's Liquid and RSK Labs' RSK. These are all "union sidechains": The connection between Bitcoin's blockchain and sidechains is managed by an "union" comprised of well-known companies in the field. They control a multi-signature address on the Bitcoin blockchain and "move" Bitcoin through a collective signature.

Drivechains will be protected by Bitcoin miners: miners on the Bitcoin blockchain. "Transferring" funds from the side chain back to the main chain requires a large amount of computing power over a long period of time. In addition, the drive chain requires joint mining, which means that the computing power on the Bitcoin blockchain also protects this side chain.

To achieve this, Tierion developers Paul Sztorc and CryptAxe proposed two soft forks. The first one is called Hashrate Escrows, which will lock the funds in the Bitcoin blockchain contract ("moving" them to the sidechain), and only unlock the funds when the hashrate is enough (moving the funds "moving" "To the Bitcoin blockchain). The second soft fork is called Blind merge Mining, which will give the sidechain the same computing power as the Bitcoin blockchain.

The controversy over the drive chain is that it may give bitcoin miners more power. Some people also recommend using the Noinput category for Blind merge Mining.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!