Taproot is coming: first major Bitcoin update since 2017

Taproot is coming: first major Bitcoin update since 2017

Bitcoin hasn’t received a major protocol upgrade since 2017. That should change in mid-November when the update called Taproot is activated. The preparatory work has been going on for a long time. Bitcoin core developer Gregory Maxwell published it back in January 2018 a first draft of Taproot on the Bitcoin mailing list. Even then, the aim of the design was more anonymity and efficiency.

The foundations for Taproot were laid in the turbulent Bitcoin year 2017 with the introduction of Segregated Witness (SegWit). The disputes over potential block size changes and the introduction of SegWit had eventually led to a split in Bitcoin.

As with SegWit, Taproot is also a soft fork. The changes to the protocol will therefore be backwards compatible. This is an advantage because in a decentralized network it can take some time before the participants switch to new software and all transactions have been converted to a new format. Currently using around 80 percent of the transactions the SegWit format in the Bitcoin network.

The Taproot upgrade offers with the new Pay-to-Taproot (P2TR) transaction types, which combine the concepts of Schnorr signatures and “Merklized Alternative Script Trees” (MAST), moreover, the privacy of transactions is increased and significantly less with complex output conditions Requires storage space. Overall, the upgrade consists of three Bitcoin Improvement Proposals (BIPs):

  • Schnorr signatures (BIP340)
  • SegWit output conditions (BIP341)
  • Validation of taproot scripts (BIP342)

The BIPs mentioned above define a standard for Schnorr signatures and the Taproot construction. BIP341 also builds on the earlier Merklized Alternative Script Trees (MAST) proposal. To understand what Taproot and Schnorr signatures improve in detail, let’s first take a look at the current status of Bitcoin transactions.

One of the most important concepts in Bitcoin is transactions. These “transfer” a value in the form of satoshis (sats), the smallest Bitcoin unit, from one address to another address in the Bitcoin network. For example, from Alice in a café, who is currently paying for a cappuccino with Bitcoin and sending it to Kate’s public wallet address.

A transaction generally references earlier transactions as transaction inputs. The only exception to this are the Coinbase transactions, with which the reward is distributed to the successful miner with each new block and thus new Bitcoins are created. Transactions are not encrypted. It is thus possible to search through every transaction that has been persisted in the Bitcoin blockchain and to see the details.

In our café example, Alice transfers ownership of the satoshis for the cappuccino to Kate, so to speak. If Kate later buys something with these Satoshis, she would in turn pass the property rights on to the Satoshis. The amount for the cappuccino is saved along with other information in an Unspent Transaction Output (UTXO). There Alice determines who can spend the satoshis for the cappuccino that has just been paid for. This contract is recorded in a so-called issue condition in the scriptPubKey field of the transaction.

Output conditions are complex or less complex scripts that are written in Bitcoin’s own script language. Script is a stack-based language that is similar to Forth and is not Turing-exhaustive. Because of the possibility of enriching scripts with your own logic, the name “Programmable Money” is often used for Bitcoin. In the case of Ethereum and other cryptocurrencies, smart contracts are also used, with Ethereum relying on Turing completeness.

The output conditions for Alice’s cappuccino transaction could be, for example: The satoshis for the cappuccino can only be reissued by someone who can provide a valid signature that matches Kate’s wallet address (public key hash). In this case, this would only be possible with Kate’s private key. The type of transaction just described is called Pay-to-Public-Key-Hash (P2PKH) and is around 78 percent the most frequently used type of transaction.

The receiving address for a P2PKH transaction can be easily recognized in a block explorer based on the leading “1” in the address. The output conditions can also be formulated in a more complex way, for example in a multi-signature setup in which the script expects several signatures at the same time. In such a case, a different type of transaction should be used: With Pay-to-Script-Hash (P2SH), complex output conditions are recorded by a hash in the transaction in the scriptPubKey field. The unhashed plaintext version of the output condition is called the Redeem script.

If a P2SH transaction is to be issued successfully, it must contain the appropriate Redeem script. This must match the “Redeem hash” generated previously and contain additional data such as signatures for successful script evaluation. In a complex multi-signature setup or in general with complex output conditions, the Redeem script can take up considerable memory space. Even if only 3 signatures are required to release the Satoshis in a 3-out-of-5 multi-signature setup of 5 signatures, the Redeem script also contains sections for all alternative paths.

This translates into higher transaction costs, as fees are charged for every byte of storage space. It also reveals unnecessarily many details about all scripts in the output conditions. The Bitcoin Improvement Proposal 341 aims to minimize precisely these two problems.

Article Source