What is Taproot?

General perception of the privacy of Bitcoin has shifted towards more emphasis on improving it as the privacy-oriented cryptocurrency market grows and attack ways to de-anonymize users are revealed. From Dandelion++ to Chaumian CoinJoins, many initiatives are underway to strengthen the privacy assurance of Bitcoin pseudonymous.

In particular, a significant privacy benefit for the legacy cryptocurrency is Taproot, which is expected to be included in the protocol after the integration of Schnorr Signatures – which is required as the basis for the implementation.

Originally proposed by Bitcoin developer and cryptographer Gregory Maxwell in January 2018, Taproot extends Bitcoin’s smart contract capabilities while protecting privacy by executing standard transactions. and more advanced transaction efficiency to the point of indistinguishability.

The upgrade coincides with several other development proposals including Schnorr, Graftroot and MAST – an improvement over P2SH. Several of Bitcoin’s top developers are currently working on plans to integrate both Schnorr and Taproot as a hybrid protocol improvement.

What is P2SH and MAST?

Understanding Taproot requires first evaluating some of the methods that underlie transactions in the Bitcoin network. Specifically, P2SH (known as pay to script hash) is where coins are locked in a Bitcoin contract. This contract contains scripts that define specific conditions that the coins need to meet in order for the owner to spend.

For example, standard transactions require a private key to be generated to verify that the coins can be spent. However, more advanced transactions like multi-sig require a certain threshold of the transaction signing pool before it can be sent. So, if Alice, Bob and Charlie are members of a multi-sig pool for spending X amount of bitcoins from an exchange, a multi-sig P2SH scenario might require at least 2 out of 3 participants. must sign the transaction for the outputs to be spent.

A specific output spend permission can correspond to multiple P2SH script conditions, but only one condition needs to be met to authorize spending.

The conditions of these more advanced transactions are stored in the P2SH script as hashes on the blockchain. However, once the coins are spent, all conditions are revealed to the network, whether they are conditions to be met or to allow the spending of the coins. For instance, if a 2-in-3 multi-sig condition is met before another P2SH script condition such as a time-lock also exists, then both the time-lock and the multi-sig script are revealed after the coin is spent. .

This represents privacy issues as not all Bitcoin wallets function as multi-sig and time-locked contracts. Thus, observers can infer the transaction’s native wallet type by excluding wallets that do not have the enhanced P2SH scenario conditions. Multiple conditions can also lead to heavier transactions, reducing scalability.

MAST is designed to improve P2SH by overshadowing the script conditions for a transaction. Short for Merkrelized Abstract Syntax Tree, MAST obscures the conditional scenarios of transactions and reveals only the first condition that is met – the one responsible for valid spending of transactions. coin. MAST cleverly uses Merkle Trees to hash each script condition individually instead of hashing the entire set of conditions. In doing so, the Merkle pipeline can validate that a valid condition has been met without revealing other scenario conditions.

Back to the Alice, Bob and Charlie example. If the P2SH contains both a multi-sig 2/3 condition and a timing condition, only the condition that is met first will be revealed. If Alice and Bob signed the transaction, an observer could verify that the 2/3 multisig condition was met, but they wouldn’t know that P2SH also had a timing condition.

Schnorr and Taproot

The main advantage of Schnorr signatures is the ability to aggregate transactions into a single transaction. Instead of input requiring individual signatures, the signatures of multiple transactions can be integrated into a single transaction with a single, common signature.

The prominent benefits of signature aggregation are the storage savings in each block and the better scalability of the network. However, when applying Schnorr signatures to multi-sig transactions, you need to allow Taproot.

By leveraging a trick called “threshold signature” when applying Schnorr to multi-sig transactions, participants in multi-sig can pool their signatures and public keys together to spend coins. like any standard transaction. Taproot is an innovation that connects MAST to this concept, where participants can fine-tune the threshold public key or threshold signature.

They can essentially demonstrate spend validity of a multi-sig transaction scenario condition without disclosing in the large Schnorr aggregation transaction that the transaction has complex scenario conditions. Thus, an enhanced (multi-sig) transaction can be hidden in an aggregate Schnorr signature like a regular transaction without sacrificing MAST’s Merkle path map.

Also, the transaction does not reveal that it has a MAST structure.

Schnorr, MAST, and Taproot are seen as complementary innovations that lead to some of the fascinating – and more complex – possibilities of Bitcoin transactions.

Bitcoin Core developer Anthony Towns proposed an idea a few months later in July 2018 for “taproot generalization,” which would reduce the amount of data required for the original Taproot proposal. However, he noted:

“Right at the start, I thought it would make sense to deploy schnorr/taproot/mast first and add graftroot/aggregation later. My feeling is that there is no great urgency to taproot generalization, so it makes sense to keep doing schnorr /taproot /mast, spend some time analyzing taproot in general, and if it seems like healthy and useful, aim to activate it at a later stage, e.g. at the same time as graftroot/aggregation”.

Taproot is basically ready to be deployed but requires Schnorr to be deployed first, or at least in conjunction with Taproot.

Detailed proposals for the inclusion of Schnorr in the Bitcoin Core protocol are available, however, there does not appear to be a clear timeline for implementation. The common perception is that Schnorr, MAST, and Taproot will be deployed as an additional update to the protocol.

Schnorr is a significant upgrade for Bitcoin, competing with SegWit. Major updates come with contention and delays in the community, but the support behind Schnorr is strong. The developers are working to test and improve the implementation of the upgrade technique before announcing its final preparation.

Bitcoin developers and the wider community have long been excited about the potential of integrating Schnorr Signatures into the protocol, and it looks like an official announcement date is imminent in 2019. Taproot put it. offers some compelling privacy advantages as an addition to Schnorr and MAST, and the final addition of Graftroot even seeks to enhance Taproot by addressing some of its shortcomings in terms of performance.

Bitcoin performance and privacy have been at the heart of the community for years, and meaningful strides have been made with innovations like SegWit, Stonewall, and Chaumian CoinJoins. Many other proposals will undergo further development throughout 2019 and serve as some compelling enhancements to the continuously evolving Bitcoin network.

See more:

According to Tapchibitcoin

Follow the Twitter page | Subscribe to Telegram channel | Follow the Facebook page