<blockquote>
<p>Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree?</p>
</blockquote>
<p>It isn't necessarily a bug that a Taproot tree allows a leaf script to be repeated on multiple levels of the tree on construction and even if it was there would be no way to address this as the Taproot tree is only (partially) revealed at spending time. However it presents a malleability vector if at spending time the same Tapleaf can be spent from at multiple levels on the tree.</p>
<blockquote>
<p>If Taproot was (hypothetically) redesigned today would it address this bug and how?</p>
</blockquote>
<p>Yes if it was redesigned today it would at spending time require signing the entire Merkle path rather than just the Tapleaf. This doesn't prevent a Tapleaf from being repeated on Taptree construction but would prevent the same Tapleaf being spent from on a different level of the Taptree.</p>
<p>ghost43 stated on IRC:</p>
<blockquote>
<p>If the Merkle path to the Tapleaf was signed it would not be interesting whether there is a duplicate Tapleaf in the tree. The issue is that as the Tapleaf path is not signed, if the Tapleaf is duplicated anyone with knowledge of the Taptree can &quot;rebind&quot; the spend to refer to the other matching Tapleaf. It is a sort of malleability. If the path to the leaf was signed this would not be possible.</p>
</blockquote>
<p>Thanks to ghost43 and AJ Towns for answering this on IRC.</p>

CC BY-SA 4.0
2023-02-09T12:08:41.033Z
2023-02-09T12:08:41.033Z
Michael Folkson
<p>On the bitcoin-dev mailing list Russell O'Connor <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021452.html" rel="nofollow noreferrer">stated</a>:</p>
<blockquote>
<p>There is a bug in Taproot that allows the same Tapleaf to be repeated
multiple times in the same Taproot, potentially at different Taplevels
incurring different Tapfee rates.</p>
<p>The countermeasure is that you should always know the entire Taptree
when interacting with someone's Tapspend.</p>
</blockquote>
<p>Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree? If Taproot was (hypothetically) redesigned today would it address this bug and how?</p>

CC BY-SA 4.0
2023-02-09T12:29:03.447Z
Shouldn't you always want to know the entire Taptree anyway? Otherwise someone can sneak in a script that allows them to unilaterally spend the UTXO.
Vojtěch Strnad
CC BY-SA 4.0
2023-02-09T12:32:51.390Z
@VojtěchStrnad: It is always hard to generalize when there are multiple use cases and multiple possible environments. You could say have a business where the CEO knows the entire tree and individual employees know individual Tapleaves so the CEO has access to all spending paths while individual employees only have access to a subset of spending paths. So I'd say generally yes but not "always".
Michael Folkson
CC BY-SA 4.0
2023-02-09T12:45:51.460Z
If you're trusting a CEO not to steal the money, you can probably also trust them not to repeat a Tapleaf on multiple levels. Yes, it's technically a design flaw in Taproot but not one most people need to worry about.
Vojtěch Strnad
CC BY-SA 4.0
2023-02-09T12:49:44.797Z
I agree generally. But the CEO might not be able to steal the money in this scenario, they might not even have any private keys. So you aren't trusting them in that sense. They are merely the only one who has full knowledge of the tree.
Michael Folkson
<script><taproot><transaction-malleability>
Why is it a bug that a Taproot tree allows a Tapleaf to be repeated on multiple levels of the tree?
Michael Folkson
# Why is it a bug that a Taproot tree allows a Tapleaf to be repeated on multiple levels of the tree?

(Asked by: username_0 on 2023-02-09)

On the bitcoin-dev mailing list Russell O'Connor [stated](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021452.html):

> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree
> when interacting with someone's Tapspend.

Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree? If Taproot was (hypothetically) redesigned today would it address this bug and how?

**Tags:** script, taproot, transaction-malleability

> **Comments:**
> **username_1**: Shouldn't you always want to know the entire Taptree anyway? Otherwise someone can sneak in a script that allows them to unilaterally spend the UTXO.  
> **username_0**: @username_1: It is always hard to generalize when there are multiple use cases and multiple possible environments. You could say have a business where the CEO knows the entire tree and individual employees know individual Tapleaves so the CEO has access to all spending paths while individual employees only have access to a subset of spending paths. So I'd say generally yes but not "always".  
> **username_1**: If you're trusting a CEO not to steal the money, you can probably also trust them not to repeat a Tapleaf on multiple levels. Yes, it's technically a design flaw in Taproot but not one most people need to worry about.  
> **username_0**: I agree generally. But the CEO might not be able to steal the money in this scenario, they might not even have any private keys. So you aren't trusting them in that sense. They are merely the only one who has full knowledge of the tree.  

---

## 1 answers

### Answer by username_0 on 2023-02-09. Score: 1 | Accepted answer

> Why is it a bug that a Taproot tree (Taptree) allows a leaf script (Tapleaf) to be repeated on multiple levels of the tree?

It isn't necessarily a bug that a Taproot tree allows a leaf script to be repeated on multiple levels of the tree on construction and even if it was there would be no way to address this as the Taproot tree is only (partially) revealed at spending time. However it presents a malleability vector if at spending time the same Tapleaf can be spent from at multiple levels on the tree.

> If Taproot was (hypothetically) redesigned today would it address this bug and how?

Yes if it was redesigned today it would at spending time require signing the entire Merkle path rather than just the Tapleaf. This doesn't prevent a Tapleaf from being repeated on Taptree construction but would prevent the same Tapleaf being spent from on a different level of the Taptree.

ghost43 stated on IRC:

> If the Merkle path to the Tapleaf was signed it would not be interesting whether there is a duplicate Tapleaf in the tree. The issue is that as the Tapleaf path is not signed, if the Tapleaf is duplicated anyone with knowledge of the Taptree can "rebind" the spend to refer to the other matching Tapleaf. It is a sort of malleability. If the path to the leaf was signed this would not be possible.

Thanks to ghost43 and AJ Towns for answering this on IRC.


---

