<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-6" rel="nofollow noreferrer">BIP341</a>:</p>
<blockquote>
<p><strong>Why is the Merkle path length limited to 128?</strong> The optimally
space-efficient Merkle tree can be constructed based on the
probabilities of the scripts in the leaves, using the Huffman
algorithm. This algorithm will construct branches with lengths
approximately equal to <em>log<sub>2</sub>(1/probability)</em>, but to have branches
longer than 128 you would need to have scripts with an execution
chance below 1 in <em>2<sup>128</sup></em>. As that is our security bound, scripts that
truly have such a low chance can probably be removed entirely.</p>
</blockquote>
<p>This is an excellent explanation why one really doesn't need a Merkle tree deeper than 128, but it doesn't explain why it's not allowed. Would this open the protocol to some sort of attack? I don't see how a script path spend with a few thousand branch steps would be worse than multiple individual transactions with shorter branches. Or it is just a standard to set a limit like this in a protocol when confident enough that nobody could ever need to go over it?</p>

CC BY-SA 4.0
2022-08-16T21:00:17.557Z
@Murch I believe that OP by "a few thousand branches" means "a single control block with a few thousand Merkle branch steps". The actual number of possible branches isn't relevant here, as only one gets revealed.
Pieter Wuille
CC BY-SA 4.0
2022-08-16T21:07:37.407Z
Observation by Pieter is correct. I'm definitely not suggesting the limit isn't generous enough, as no one will be going around constructing Merkle trees with 2^128 different valid conditions anytime soon. But constructing an output with a spendable Merkle path 128 branches long is very much possible.
Vojtěch Strnad
<taproot><mast>
Why is the Taproot Merkle path length limited to 128?
Vojtěch Strnad
# Why is the Taproot Merkle path length limited to 128?

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

From [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-6):

> **Why is the Merkle path length limited to 128?** The optimally
> space-efficient Merkle tree can be constructed based on the
> probabilities of the scripts in the leaves, using the Huffman
> algorithm. This algorithm will construct branches with lengths
> approximately equal to *log2(1/probability)*, but to have branches
> longer than 128 you would need to have scripts with an execution
> chance below 1 in *2128*. As that is our security bound, scripts that
> truly have such a low chance can probably be removed entirely.

This is an excellent explanation why one really doesn't need a Merkle tree deeper than 128, but it doesn't explain why it's not allowed. Would this open the protocol to some sort of attack? I don't see how a script path spend with a few thousand branch steps would be worse than multiple individual transactions with shorter branches. Or it is just a standard to set a limit like this in a protocol when confident enough that nobody could ever need to go over it?

**Tags:** taproot, mast

> **Comments:**
> **username_1**: @Murch I believe that OP by "a few thousand branches" means "a single control block with a few thousand Merkle branch steps". The actual number of possible branches isn't relevant here, as only one gets revealed.  
> **username_0**: Observation by Pieter is correct. I'm definitely not suggesting the limit isn't generous enough, as no one will be going around constructing Merkle trees with 2^128 different valid conditions anytime soon. But constructing an output with a spendable Merkle path 128 branches long is very much possible.  

---

## 0 answers

