> For the complete documentation index, see [llms.txt](https://docs.bevm.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bevm.io/architecture-and-concepts/concept/taproot.md).

# Taproot

## What is Taproot?

The core of Taproot is composed of Schnorr signatures and MAST abstract syntax trees.

We'll focus on the creation of Taproot public keys and the spending pattern.

### I. Create Taproot public keys

To create a Taproot public key, it is important to understand the process of generating **aggregated public keys** and **aggregated signatures.**

The related research focus on MuSig1 and MuSig2, it says MuSig1 is more complicated because it requires three rounds of communication to create a signature, with each round consisting of back-and-forth message exchanges.

#### **i. Aggregated public keys**

<figure><img src="/files/EqJrs5KxZjocdyuO3yOv" alt=""><figcaption></figcaption></figure>

From the above diagram, we can see that the generation process of aggregated public keys can be divided into three steps:

1. Public keys are exchanged between parties, and all the public keys are concatenated and hashed once to generate c\_all.
2. c\_all is concatenated with the public key i and hashed to generate the factor c\_i.
3. The aggregated public key P\_agg is obtained by linearly combining the public keys using the factor c\_i.

<figure><img src="/files/BKwzUTeMyXqboT8SitD6" alt=""><figcaption></figcaption></figure>

#### **ii. Aggregated signatures**

<figure><img src="/files/JA326WFgRv5pyKcXr9Mm" alt=""><figcaption></figcaption></figure>

The generation process of aggregated signatures, as shown in the diagram, requires three rounds of communication and can be divided into two main steps:

1. Nonces are generated and linearly aggregated to obtain R\_agg.
2. Each party uses their private key to generate Schnorr signatures and then aggregates them to obtain the final aggregated signature (R\_agg, s1+s2+s3).

### II. MAST abstract syntax tree

<figure><img src="/files/G7HOJsnFhCy70dwr4QXj" alt=""><figcaption></figcaption></figure>

As shown in the above diagram, a Taproot public key consists of two main components: the aggregated public key <mark style="color:blue;">P</mark> and the public key formed by the MAST structure, denoted as <mark style="color:blue;">tG</mark>.&#x20;

Assuming <mark style="color:blue;">P</mark> 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. Then the&#x20;

Taproot public key creation process is as follows:

**1)Generate public and private keys for each one.**

<figure><img src="/files/Oa7mqgCQfjKpLST3RUte" alt=""><figcaption></figcaption></figure>

**2)The public key is aggregated into pubkey\_agg and the private key is adjusted for later signing.**

<figure><img src="/files/Ex4dBgRs0apqehGHqf3r" alt=""><figcaption></figcaption></figure>

**3)Create scripts script\_A, script\_B, script\_C**

![](/files/GBBbB8vS2HqpatddQ7LY)

**4)Build the MAST abstract syntax tree**&#x20;

Calculate the private key <mark style="color:blue;">taptweak</mark> corresponding to the MAST structure. In the figure above, TaggedHash represents a hash with a label, with a fixed length of 32 bytes, it calculated as:

**TaggedHash(tag, x) = sha256(sha256(tag) + sha256(tag) + x)**

> <mark style="color:blue;">ver</mark> represents the Tapscript version number, which is currently <mark style="color:blue;">0xc0</mark>;&#x20;
>
> <mark style="color:blue;">size</mark> represents the number of bytes of the scirpt;&#x20;
>
> A\&B means A, and the B dictionary is sorted and spliced by bytes.

<figure><img src="/files/1waqgnqFFuBCIRUUkhrF" alt=""><figcaption></figcaption></figure>

**5)According to the formula&#x20;**<mark style="color:blue;">**Q=P+tG**</mark>**&#x20;to generate the taproot public key and segwit\_address for the following transaction.**

<figure><img src="/files/SpiaubaJKH2hr4jMQL5t" alt=""><figcaption></figcaption></figure>

**6)Transfer 50 BTC to the Taproot address.**

<figure><img src="/files/NbMKLZJYc3uSs6OgzvsG" alt=""><figcaption></figcaption></figure>

### III. The cost of Taproot

To complete the transfer to Bob, there are two payment options:&#x20;

#### 1) Formed an aggregated signature signed by Alice, Bob, and Charlie.

**i. Fill in all data like the original text of the transaction, the recipient's address, the amount, etc.**

If we follow the first option, we need Alice, Bob, and Charlie to sign the transaction respectively and then generate their own nonce to aggregate them.

Finally, aggregating the signatures. As a result, the witness script for this option is a single signature with a fixed length of 64 bytes.

<figure><img src="/files/1a2NrWvvwVzJateBfXFO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/taEq2EeNaTcAvvcuMndM" alt=""><figcaption></figcaption></figure>

**ii. Test whether the original of the transaction formed by the first cost is legitimate and send the transaction.**

<figure><img src="/files/cUKYaK1imPAbeW0xG5UE" alt=""><figcaption></figcaption></figure>

#### 2) Use the script in the MAST structure to transfer.

To perform the second method, where Alice uses script\_A, the witness script should include the following components:

1. \[Stack element(s) satisfying TapScript\_A]
2. \[TapScript\_A]  \[Controlblock c]

Here, \[Controlblock c] represents the proof associated with TapScript\_A, with a length of 33 + 32n.&#x20;

The first byte of the 33-byte sequence is calculated based on the aggregate public key and the Taproot version number.&#x20;

The remaining 32 bytes represent the x-coordinate of the aggregate public key. 32n represents the proof for TapScript\_A, and in this example, n is equal to 2, indicating taggedhash\_leafB and taggedhash\_leafC.

<figure><img src="/files/9KUNNpqOFOHmCA05tFwJ" alt=""><figcaption></figcaption></figure>

Test the second type of transaction formed by spending the original text and send the transaction.