Taproot: Privacy, Security, Scalability and truly decentralized application protocols

With Taproot only a few hours from activation, it seems like a good time to expand on the Taproot part from a previous ELI5 shared a few months ago.

Taproot is arguably the biggest upgrade to Bitcoin's base-layer protocol, introducing a new signature algorithm and scripting language. It brings a set of protocols that enhance Bitcoin's privacy, security, scalability, fungibility and unlocks the infrastructure that will allow for seamless integration of L2/sidechain application protocols on Bitcoin.

Taproot was activated through the "speedy trial" approach. Under the speedy trial, miners were given three months to signal support for Taproot after the code was shipped. This required 90% of the blocks in a difficulty epoch(2016 blocks) to signal for Taproot. Activation was achieved at block height 687284 back in June.

Although some of the ideas included in the upgrade have been discussed for many years, the final iteration of Taproot was proposed by Bitcoin developer Gregory Maxwell in 2018. The upgrade is named after one of the three Bitcoin Improvement Proposals (BIPs) included in the upgrade - Schnorr Signatures(BIP 340), Taproot(BIP 341) and Tapscript(BIP 342).

By combining Schnorr signatures with MAST (Merklized Alternative Script Tree) and introducing a new, slightly modified scripting language called Tapscript, Taproot expands Bitcoin's smart contract capabilities, while offering more privacy and security by making multi-signature transactions and complex smart contracts indistinguishable from regular bitcoin transactions.

​

Schnorr signatures (BIP 340)

This part of the upgrade is a change to Bitcoin's cryptographic digital signature algorithm. In asymmetric cryptography (public-private key pairs), digital signature algorithms define the generation of digital signatures using a private key that proves the ownership of a corresponding public key.

The existing Elliptic Curve Digital Signature Algorithm (ECDSA) of Bitcoin will not be replaced, but Schnorr signatures will be implemented in addition to it.

The Schnorr digital signature algorithm allows for something called key and signature aggregation using a protocol known as MuSig - multiple signatures created using multiple private keys corresponding to multiple public keys are combined to produce a single cryptographic digital signature corresponding to a single public key recorded on the blockchain.

Key and signature aggregation

In addition to Schnorr signatures and public keys being smaller than ECDSA signatures and public keys, aggregation further helps reduce the footprint of multi-signature transactions and complex smart contracts, which will take up the same space as regular single-signature transactions and as all transactions will look indistinguishable on the blockchain, the privacy benefits are fairly obvious. The privacy also extends to Lightning Network as on-chain transactions to open and close Lightning channels can no longer be identified from the keys and signatures in the channel or the script used.

Unlike ECDSA signatures, Schnorr signatures are provably secure and inherently non-malleable, meaning a third party cannot alter an existing valid signature under any circumstance. Segregated Witness (SegWit) addressed transaction malleability, Schnorr signatures address signature malleability.

There are also significant computational benefits for nodes, as key aggregation will allow nodes to verify signatures in batches, but these benefits can only be realized with time once Schnorr signatures become widely adopted.

Modifying the digital signature algorithm, per se, doesn't affect anything on the blockchain. Schnorr is a different, more efficient way of generating digital signatures.

When Satoshi originally developed Bitcoin, Claus Peter Schnorr, the inventor of Schnorr signatures, had a patent on it. It is speculated that Satoshi may have otherwise opted for Schnorr signatures over ECDSA, which was a rigorously tested open-source alternative developed later, even if in a somewhat obligately inefficient manner as to not constitute an infringement of the patent, which expired in 2008.

There was a suggestion to use a different name, Discrete Logarithm Signatures was briefly mooted, while adapting Schnorr signatures for Bitcoin as some people felt that Claus Peter Schnorr's name shouldn't be used in association with Bitcoin after he prevented the widespread use of such a powerful signature scheme for over 20 years.

​

Taproot (BIP 341)

This part of the upgrade leverages the Schnorr signature scheme to enable Merklized Alternative Script Trees (MAST) and defines the rules for a new output type based on SegWit known as Pay-to-Taproot(P2TR) to allow for the new capabilities of Schnorr signatures.

MAST is a privacy solution that uses Merkle trees as part of the script's structure to address some long-standing issues with transactions using Pay-to-Script Hash (P2SH) and Pay-to-Pubkey Hash (P2PKH) locking scripts where all possible spending conditions of a transaction are revealed.

P2TR significantly optimizes for block space economy

P2TR combines two separate locking scripts - P2SH and Pay to Pubkey (P2PK), which is a simpler version of P2PKH that locks an output to the public key rather than a hash of the public key.

This allows P2TR outputs to be spent by either a script (smart contract) or a public key, but by allowing different spending conditions of the output to be individually hashed, only the specific spending condition met is revealed and thanks to Schnorr signatures, they're all indistinguishable on the blockchain.

​

Tapscript (BIP 342)

This part of the upgrade modifies Bitcoin's scripting language to enable the new transaction types introduced by the two proposals above using new opcodes (operation codes), which are commands in Bitcoin scripts with predefined functions.

The goal of Tapscript is to make Schnorr signatures, batch verification and signature hash improvements available to spends that use the script path as well as the public key path. It enables nodes to create and validate P2TR outputs.

Existing signature opcodes for ECDSA are modified to verify Schnorr signatures. Two existing opcodes that define verification of multi-signature transactions are disabled and replaced with a new opcode (OP_CHECKSIGADD) to enable batch verification of signatures.

Tapscript also allows adding new signature validation rules through softforks and introduces another new opcode (OP_SUCCESS) to enable the seamless introduction of future opcodes to Tapscript.

​

Impact of Taproot

Bitcoin's script is deliberately limited and intentionally non-Turing complete in order to retain simplicity, security and efficiency. Linear optimization is one of the main considerations for upgrades to the script to ensure decentralization - that any individual can economically self-host a node and trustlessly validate the blockchain.

Taproot is a forward-compatible soft fork, meaning old non-upgraded nodes will recognize the new blocks as valid. At the time of writing, more than 53% of ~ 60,000 Bitcoin nodes support Taproot. Non-enforcing nodes will reject transactions spending from P2TR outputs until they upgrade node software but will accept blocks containing transactions spending from P2TR outputs.

The significance of Taproot cannot be measured merely by what the above proposals enable for Bitcoin but what they represent for the future of Bitcoin, by introducing new tools to make future upgrades easier to implement, simpler, safer and more private.

Such upgrades waiting in the wings include cross-input signature aggregation, channel factories, state chains and covenants, which enable advanced application protocols to be built on top of Bitcoin without placing any undue burden on full-node users, thereby preserving Bitcoin's inviolable security and decentralization.