To address efficiency, privacy, and flexibility issues within the Bitcoin network, the Bitcoin development community implemented the Taproot upgrade at the end of 2021. The core components of this upgrade include Schnorr signatures and MAST (Merkelized Abstract Syntax Tree).

Schnorr's key aggregation feature allows participants in a single multi-signature transaction to collaboratively combine their public keys and generate an aggregate signature that is valid for the sum of their public keys. This saves block space, enhances privacy, and enables faster transaction verification. MAST improves the privacy and efficiency of Bitcoin scripts by breaking down complex Bitcoin scripts into smaller sub-scripts and utilizing the Merkle tree structure.

To fully understand how Taproot operates, this article explains the Taproot transaction process from two main aspects: the creation of the Taproot public key and the spending patterns of Taproot.

Creating the Taproot Public Key

To create a Taproot public key, we first need to understand the process of generating an aggregated public key and aggregated signature. The most notable related research includes MuSig1 and MuSig2. Compared to MuSig2's two-round communication mechanism, MuSig1's major drawback is that it requires three rounds of communication to create a signature, with each round consisting of back-and-forth message exchanges. Since this article does not involve inter-network communication, we will focus on the basic generation process of aggregated public keys and signatures.

Aggregated Public Key

The generation process of the aggregated public key can be divided into three steps:

1. Exchange public keys and perform an aggregation hash on all concatenated public keys to generate `c_all`.
2. Concatenate `c_all` with each participant's public key and perform a hash to generate the factor `c_i`.
3. Linearly combine the factors `c_i` to obtain the aggregated public key `P_agg`.

Aggregated Signature

The generation process of the aggregated signature requires three rounds of communication and can be divided into two main steps:

1. Generate nonces and linearly aggregate them to form `R_agg`.
2. Each participant uses their private key to generate a Schnorr signature, and these signatures are then aggregated to obtain the final aggregated signature `(R_agg, s1+s2+s3)`.

Introducing MAST

As shown in the diagram, the Taproot public key primarily consists of two parts: the aggregated public key `P` and the public key `tG` formed by the MAST structure. Assuming `P` is the aggregated public key of Alice, Bob, and Charlie, and `script_A`, `script_B`, and `script_C` are the scripts related to Alice, Bob, and Charlie respectively, the Taproot public key creation process is as follows:

1. Alice, Bob, and Charlie each generate their own public and private keys.

      2.The public keys are aggregated into `pubkey_agg`, and the private keys are adjusted for future signatures.

        3. Create scripts `script_A`, `script_B`, and `script_C`.

        4. Construct the MAST, and calculate the private key `taptweak` corresponding to the MAST structure. In the diagram, `TaggedHash` represents a         tagged hash with a fixed length of 32 bytes, calculated as `TaggedHash(tag, x) = sha256(sha256(tag) + sha256(tag) + x)`. `ver` represents the         Tapscript version number, currently set to `0xc0`, and `size` represents the byte size of the script. `A&B` represents the concatenation of `A` and `B` in         dictionary order.

          5. Combine `Q=P+tG` to form the Taproot public key and generate a `segwit_address` for the transaction.

         6. Transfer 50 BTC to the Taproot address.

Taproot Spending

To transfer 0.5 BTC from the Taproot address to Bob, there are two payment methods: one involves Alice, Bob, and Charlie all signing to form an aggregated signature, completing the transfer to Bob; the other involves using the script in the MAST structure to transfer to Bob.

1. Create the raw transaction, filling in the recipient address, transfer amount, and other data.
2. For the first method, Alice, Bob, and Charlie each generate nonces and aggregate them, then each uses their private keys to generate Schnorr signatures, and finally aggregate the signatures. Thus, the final witness script is a single signature with a fixed length of 64 bytes.
3. Test the legality of the transaction created by the first method and send the transaction.
4. For the second method, assume Alice completes the transfer to Bob through `script_A`. The witness script needs to include:

• `[Stack element(s) satisfying TapScript_A]`
• - `[TapScript_A]`
• - `[Controlblock c]`, where `[Controlblock c]` represents the proof related to `TapScript_A`, with a length of `33+32n`. The first byte of the 33 bytes is calculated from the aggregated public key and the Taproot version number, and the remaining 32 bytes represent the x-coordinate of the aggregated public key. `32n` represents the proof of `TapScript_A`, and in this example, `n=2`, referring to `taggedhash_leafB` and `taggedhash_leafC`.

       5. Test the legality of the transaction created by the second method and send the transaction.

Summary

Overall, Taproot transactions focus on one type of output and two spending patterns. One type of output ensures that the public key in the locking script is consistent, whether for individual transactions or multi-signature transactions, making it indistinguishable in form. The two spending patterns enable transaction participants to achieve more complex transactions and a wider variety of application scenarios with fewer bytes.

Recognizing the technical characteristics of the Taproot mechanism, the Bitcoin Layer 2 solution BEVM has adopted it as one of the core architectures of the "Taproot Consensus" technology. By combining Schnorr signatures and MAST, BEVM can provide a more efficient and flexible smart contract execution environment while ensuring security, pushing the entire Bitcoin ecosystem towards a more secure and efficient future.