<blockquote>
  <p>First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?</p>
</blockquote>

<p>The <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html" rel="nofollow noreferrer">taproot email</a> doesn't specify how the script is placed into the merkle tree.  It can be that each leaf node in the tree is a different script (BIP114-style) or it can be that a parameter can be passed that allows extracting multiple leaves so that parts of the script can be reused (BIP116-style).</p>

<p>The reason this detail is not in the taproot email is because that email was about rearranging the previous ideas about merklized scripts (MAST) so that the expected default condition (everybody signs) was the easiest and cheapest option to use with no need to actually handle the merkle tree in the expected case.  The ideas about how to organize and use the tree are a separate discussion.</p>

<blockquote>
  <p>Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.</p>
</blockquote>

<p>The merkle root / public key for taproot consumes a fixed number of bytes (say 64), which is trivial, but the spending transaction will have to provide the spending script as well as a <em>merkle proof</em> providing a list of hashes (and a few bits of path information) proving that the provided script connects to the taproot's merkle root.</p>

<p>This information will be subject to the fundamental block size limit of 4 million weight units and, depending on how it is implemented, may also be subject to Bitcoin's current limits on witness size (10,000 weight units for segwit v0).  The good news is that it's impossible for an honest person to create a merkle tree that requires more than about 8,000 bytes to create the merkle proof (not counting the script) even if they had at their disposal all the energy in the universe.  (Assuming we use Bitcoin's SHA256d hash function.)</p>

<p><img src="https://cdn-images-1.medium.com/max/1600/1*TJ4t6ndLPMovAWlGHgwYqg.png" alt=""></p>

<p>The above is an illustration from my <a href="https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f" rel="nofollow noreferrer">article about MAST</a> showing how the encoding of alternative scripts (subscripts) into a MAST grows at log2 whereas it grows linearly with the existing mechanism.</p>

<p>For a script with a million possible outcomes (tree depth equals 20) would require about 643 bytes (<code>20 * 32 + ceil(20 / 8)</code>), allowing actual witness script and witness data to be up to about 9,300 bytes.  Of course, if everyone signs, you don't need to provide any of that data---you just push a single signature.</p>

CC BY-SA 4.0
2018-08-17T15:12:30.127Z
Very helpful, thanks David. So what is the relationship between taproot and MAST? It seems like taproot is a proposed implementation of MAST, but with the added benefits of a consolidated pubKey?
Raz Lemniscate
CC BY-SA 4.0
2018-08-17T19:27:26.377Z
That's correct, Taproot is a form of MAST where the merkle root is combined with a public key to create a secondary public key that can be spent by the private key corresponding to the primary public key.  Basically, if you take an ECDSA public key and add an integer to it to create a secondary public key, you can create the corresponding secondary private key by adding the name integer to it.  Revealing the number later doesn't reduce the security of the primary keypair, so if you need to publicize the merkle root to use MAST, you can---but otherwise you can just sign.
David A. Harding
CC BY-SA 4.0
2018-08-16T21:13:16.723Z
2018-08-16T21:13:16.723Z
David A. Harding
<p>From my understanding, Taproot uses a Merkle Tree structure whose root represents the outcome of a script. That representation is in the form of a signature that may unlock the inputs associated with its public key counterpart, which is shared by all participants.</p>

<p>I have two questions related to this:</p>

<p>First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?</p>

<p>Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong. </p>

<smartcontracts><schnorr-signatures><taproot>
Could Taproot or Graftroot enable the execution of complex scripts?
Raz Lemniscate
# Could Taproot or Graftroot enable the execution of complex scripts?

(Asked by: username_0 on 2018-08-16)

From my understanding, Taproot uses a Merkle Tree structure whose root represents the outcome of a script. That representation is in the form of a signature that may unlock the inputs associated with its public key counterpart, which is shared by all participants.

I have two questions related to this:

First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?

Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.

**Tags:** smartcontracts, schnorr-signatures, taproot


---

## 1 answers

### Answer by username_1 on 2018-08-16. Score: 1 | Accepted answer

> First, how is the script structured in the tree? Does each path represent a different execution outcome? If so, how are the potential outcomes defined?

The [taproot email](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html) doesn't specify how the script is placed into the merkle tree. It can be that each leaf node in the tree is a different script (BIP114-style) or it can be that a parameter can be passed that allows extracting multiple leaves so that parts of the script can be reused (BIP116-style).

The reason this detail is not in the taproot email is because that email was about rearranging the previous ideas about merklized scripts (MAST) so that the expected default condition (everybody signs) was the easiest and cheapest option to use with no need to actually handle the merkle tree in the expected case. The ideas about how to organize and use the tree are a separate discussion.

> Second, if it follows a Merkle Tree structure, is there a limit in terms of the size of the script? I'm inclined to say no, given that this occurs off-chain, but I might be wrong.

The merkle root / public key for taproot consumes a fixed number of bytes (say 64), which is trivial, but the spending transaction will have to provide the spending script as well as a *merkle proof* providing a list of hashes (and a few bits of path information) proving that the provided script connects to the taproot's merkle root.

This information will be subject to the fundamental block size limit of 4 million weight units and, depending on how it is implemented, may also be subject to Bitcoin's current limits on witness size (10,000 weight units for segwit v0). The good news is that it's impossible for an honest person to create a merkle tree that requires more than about 8,000 bytes to create the merkle proof (not counting the script) even if they had at their disposal all the energy in the universe. (Assuming we use Bitcoin's SHA256d hash function.)

![](https://cdn-images-1.medium.com/max/1600/1*TJ4t6ndLPMovAWlGHgwYqg.png)

The above is an illustration from my [article about MAST](https://bitcointechtalk.com/what-is-a-bitcoin-merklized-abstract-syntax-tree-mast-33fdf2da5e2f) showing how the encoding of alternative scripts (subscripts) into a MAST grows at log2 whereas it grows linearly with the existing mechanism.

For a script with a million possible outcomes (tree depth equals 20) would require about 643 bytes (`20 * 32 + ceil(20 / 8)`), allowing actual witness script and witness data to be up to about 9,300 bytes. Of course, if everyone signs, you don't need to provide any of that data---you just push a single signature.

> **Comments:**
> **username_0**: Very helpful, thanks username_1. So what is the relationship between taproot and MAST? It seems like taproot is a proposed implementation of MAST, but with the added benefits of a consolidated pubKey?  
> **username_1**: That's correct, Taproot is a form of MAST where the merkle root is combined with a public key to create a secondary public key that can be spent by the private key corresponding to the primary public key.  Basically, if you take an ECDSA public key and add an integer to it to create a secondary public key, you can create the corresponding secondary private key by adding the name integer to it.  Revealing the number later doesn't reduce the security of the primary keypair, so if you need to publicize the merkle root to use MAST, you can---but otherwise you can just sign.  

---

