1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 05:12:47 +01:00

Merge pull request #1731 from JeremyRubin/patch-12

[BIP-0349] Add Re-Keying explanation to OP_INTERNALKEY
This commit is contained in:
Mark "Murch" Erhardt 2024-12-27 10:06:03 -05:00 committed by GitHub
commit b509e6c85f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194

View File

@ -42,6 +42,25 @@ Note: The internal key must be the X coordinate of a point on the SECP256K1
curve, so any such hash must be checked and modified until it is such an X
coordinate. This will typically take approximately 2 attempts.
### Re-Keying with Merkle Root Preservation
Consider a program such `CTV <X> CSFS <S+1> CLTV`. Such fragments are useful for LN-Symmetry applications.
Such a program would be embedded within a Taproot script path, such as `TR(X, {CTV <X> CSFS <S+1> CLTV})`.
Were the internal key to be updated from `X` to `Y`, the resulting program would be: `TR(Y, {CTV <X> CSFS <S+1> CLTV})`.
The key in the leaf and the key-path would be mismatched. Were `OP_INTERNALKEY` to be used,
the leaf would automatically re-key.
E.g., `TR(X, {CTV OP_INTERNALKEY CSFS <S+1> CLTV})` is equivalent to `TR(X, {CTV <X> CSFS <S+1> CLTV})`
and `TR(Y, {CTV OP_INTERNALKEY CSFS <S+1> CLTV})` is equivalent to `TR(Y, {CTV <Y> CSFS <S+1> CLTV})`.
While this particular example is contrived, the general technique of using `OP_INTERNALKEY`
as updatable across an entire script tree is a helpful covenant primitive when it is desirable to
invalidate signatures from prior states. For example, the theoretical `OP_TAPLEAFUPDATEVERIFY` opcode
modifies the internal key directly to remove or add a participant, and `OP_INTERNALKEY` would ensure
that the tweaked key is used from all script paths where desired.
## Reference Implementation
A reference implementation is provided here: