# Public key recovery for EC leaves in P2MR (BIP-360)

**URL:** <https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603>\
**Category:** Protocol Design\
**Tags:** taproot, softfork, cryptography\
**Created:** [June 6, 2026, 9:55pm UTC](https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603 "2026-06-06T21:55:49Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![sipa](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/sipa/32/1100_2.png) [@sipa](https://delvingbitcoin.org/u/sipa)\
**Post date:** [June 7, 2026, 2:09pm UTC](https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603/4 "2026-06-07T14:09:27Z")

</div>

> [@starius](#):
>
> If there is a tree with related EC keys `P` and `P' = P + t⋅G` in different leaves of the same tree and `e` does not commit to the control block (i.e. to the path in the tree), then it is possible to forge a signature for `P'` given a valid signature for `P`.

Right, nice catch.

> [@starius](#):
>
> **UPD**. I assume that in the P2TR case in the table there is only a single script leaf, because the key path is the key spend, not a leaf. For a literal 2-leaf P2TR output, the **script spend** would be 32 bytes larger.

Yeah, I just meant an output that allows spending through either a key or a script path. Whether that’s tweak-based of tree-based is an implementation detail of the scheme.

---

_[View the full topic](https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603)._