A list of changes and updates in the Bitcoin blockchain

Bitcoin has remained unchanged at the consensus level for more than two years. Since the activation of Segregated Witness (SegWit) in AugustIn 2017, neither hard forks nor software forks were held, which marks the longest period without consensus forks in the history of bitcoin.

This deadline, however, may soon be interrupted. Several backward compatible software forks are currently under development. According to optimistic forecasts, some of them can be launched in 2020, if, of course, they receive sufficient support in the Bitcoin ecosystem.

Schnorr / taproot / capscript

Many cryptographers consider Schnorr's signatures to be the besttype of cryptographic signatures in the area in question. They offer a high degree of accuracy, do not suffer from plasticity and are relatively fast for verification, and, which is perhaps the most interesting, allow calculations. Here is an example of one advantage for Bitcoin: several signatures can be combined into one, which can serve as an economic incentive for CoinJoin's private transactions.

Preparing to add Schnorr's signatures toBitcoin protocol has been going on for a long time. Over the past year, developers working on this proposal, including Peter Wullet and Jonas Nick of Blockstream, as well as Anthony Townes of Xapo, have revealed an even more ambitious plan. Schnorr signatures can be implemented as part of the global software fork Taproot, proposed by bitcoin developer Gregory Maxwell, who was inspired by the older idea of ​​MAST (merklized abstract syntax tree).

Bitcoins can be fixed so thattheir spending required the fulfillment of certain conditions, for example, by time or a hidden number of users who agree to unlock coins. MAST allows you to hash various conditions and include them in the Merkle tree - a compact cryptographic data structure. Thus, the coins will be blocked in the final part of this Merkle tree - its root. To spend these coins, it will be enough for the user to reveal the condition that he decides to use. Alternative ways to unlock these coins will forever remain hidden from the eyes of strangers.

Taproot has an interesting conceptexpanding this approach: regardless of complexity, almost any MAST-construction can (and should) include a condition that will allow all participants to agree on the result and together approve the settlement transaction. A joint decision will be above all other conditions.

Taproot uses this concept and signatureSchnorra so that the joint solution looks like a normal bitcoin transaction. In other words, the joint decision is implemented through a joint signature, which for everyone else looks like a regular signature. This allows you to completely hide the MAST-design, increase privacy and efficiency.

Taproot can also be enabled.an improved version of the Bitcoin programming language Script, which in this case is called “Tapscript”. Thanks to this, it will be easier to add new functions or the so-called “operation codes” (OP code) to Bitcoin in the future.

Taproot does not cause too much controversy, but developers continue to discuss specific implementation details.

Great consensus cleansing

Great ConsensusCleanup) is another software fork proposed by developer Matt Corallo, who currently works as part of the Square Crypto team. Unlike the other updates described in this article, the great consensus cleaning does not imply adding new features or capabilities to Bitcoin. Instead, as the name suggests, software fork will eliminate some border vulnerabilities in the Bitcoin protocol.

These vulnerabilities are quite technical.character and "hide in the bushes." These include, for example, minor transactions that require significant computational resources for validation, irrelevant methods for updating portions of the protocol and a weak spot in the algorithm for adjusting the complexity of bitcoin. The presence of these vulnerabilities has been known for some time, but in general it is believed that they are too costly for profitable execution or the consequences of their execution will be easily eliminated. At the same time, their liquidation will make Bitcoin a little more reliable and simplify the development of cryptocurrency implementations a bit.

The main objection to this software forkdue to the fact that some changes, in theory, may make the expenditure of certain existing coins impossible. Although the very existence of such coins is extremely unlikely, this cannot be known for sure. Some find the described risk unacceptable.

Class noinput

Bitcoin transactions includecryptographic signatures confirming that the public key holder really wants to spend the corresponding coins in this particular transaction, but not the entire signed transaction. What part of the signed transaction really needs to be spent is determined using the sighash tag mechanism.

Blockstream developer Christian Decker and Townes ofXapo is proposing a new sighash label class. They are called "SIGHASH_NOINPUT", "SIGHASH_ANYPREVOUT" and "SIGHASH_ANYPREVOUTANYSCRIPT" and offer similar solutions, so for simplicity we will call them the "class Noinput".

If the sighash label in the Noinput class is included intransaction, she says that the outputs (part of the transaction responsible for receiving coins) and some other transaction data will be signed, but this will not be done with inputs (part of the transaction responsible for sending coins). By refusing to sign the entry, you can carry out the transaction even after its initial signing and change the entry to another compatible one.

Most often, such compatible inputs do not exist. The signature corresponds to the public key, which, in turn, corresponds to a strictly defined coin. Replacing the input with another will violate this connection and invalidate the transaction.

However, there are exceptions when inputTransactions can indeed be replaced. For example, bitcoin transactions for a new type of Lightning Network payment channel protocol called “Eltoo” allow you to replace the input with another compatible one. This allows you to significantly simplify the execution of payment channels. Most importantly, bugs and other unintentional errors will no longer lead to a loss of funds in the channel, and users will have to pay much less attention to backing up data.

The main objection is thatSIGHASH_NOINPUT, in particular, may be unsafe if used improperly. SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT fix this problem (and make the solution compatible with Taproot), but entail a significant complication of the process. Some suggest solving the task with OP_CHECKTEMPLATEVERIFY (described below) or OP_cat (a disabled operation code that can be activated again, possibly with Tapscript).

OP_CHECKTEMPLATEVERIFY

OP_CHECKTEMPLATEVERIFY (CTV), formerly known asOP_SECURETHEBAG, is the new opcode offered by Bitcoin Core contributor Jeremy Rubin. Its main advantage is to alleviate the problems of congestion of the Bitcoin network and fees during peak hours by conditionally increasing its throughput.

CTV will allow, in its way, to break the transactionbitcoin in two. The “sending” part of the transaction will include inputs, and the “receiving” part will include outputs. The two parts will be connected to each other through a special output included in the “sending” part. This output will contain a cryptographic hash: a random sequence of numbers at first glance, which will appear as a unique serial number connecting the “sending” part with the “receiving” one. Coins sent in a “sending” transaction can only be received by receiving a “receiving” transaction.

The bottom line is that the two parts of the transaction are transferred tonetwork with one important difference. A “sending” transaction includes a relatively large commission to guarantee its quick confirmation. The “receiving” part includes a relatively small commission - it can be confirmed later.

Waiting for the second part of the transaction with relativelya small commission should not be a particular problem for the recipient, since confirmation of the “sending” part will be enough to guarantee that the money will come with the “receiving” part. These funds will be blocked on the blockchain and will not go to anyone else's wallet, except for the recipient's wallet.

If the recipient wants to expedite the confirmation“Receiving” transactions, for example, for further spending of these coins, he can spend money directly from an unconfirmed “receiving” transaction using the “child pays for parent” method. More interestingly, CTV allows you to create even more effective solutions by breaking the “receiving” transaction into several smaller transactions, called tree payments.

The main objection is that there may be other, more effective methods for achieving the same effect. Some claim that this can be implemented through the Noinput class.

Drivechain

Sidechains are blockchains tied tothe main blockchain of bitcoin. They allow you to move coins between the sidechain itself and the bitcoin blockchain. As soon as the coins appear in the sidechain, they obey the rules in force in this particular blockchain. The rules may vary, as in the whole variety of blockchains existing today. For example, you can create a “Zcash sidechain” to ensure privacy, an “Ethereum sidechain” for smart contracts, and a “big block sidechain” to reduce commissions.

Certain sidechains already exist. The most famous examples are Blockstream Liquid (primarily for transferring funds between exchanges) and RSK from RSK Labs (Ethereum sidechain). These are “federated sidechains,” where the bridge between the Bitcoin blockchain and sidechains is controlled by a “federation” of well-known companies. In fact, they control the address with multi-signature in the Bitcoin blockchain and together sign the movement of coins back and forth.

Drivechain will be protected by Bitcoin miners -by the same miners who now allocate computing power to protect the Bitcoin blockchain. Transferring funds from the sidechain back to the main chain will require most of the hash power over a long period of time. In addition, for such sidechains, the possibility of joint mining is provided. In other words, the hash powers that are used on the Bitcoin blockchain can also be used on the sidechain.

To implement this idea, the developer TierionPaul Storz and the pseudonymous developer CryptAxe offer two software forks. The first, an “escrow hash rate”, will allow you to block the funds in the contract on the Bitcoin blockchain (“transfer” them to the sidechain), followed by unlocking (“return” them to the blockchain) upon reaching sufficient consent from the hashrate owners. The second, “blind combined mining”, will allow you to protect sidechains with the same computing power that works in the bitcoin blockchain.

Drivechain is a rather controversial update, as it is supposed to expand the powers of miners. Some propose to implement blind combined mining through the Noinput class.

</p>

Rate this publication