bips/bip-0448.md

```
  BIP: 448
  Layer: Consensus (soft fork)
  Title: Taproot-native (Re)bindable Transactions
  Authors: Gregory Sanders <gsanders87@gmail.com>
           Antoine Poinsot <mail@antoinep.com>
           Steven Roose <steven@stevenroose.org>
  Status: Draft
  Type: Specification
  Assigned: 2026-03-11
  License: CC0-1.0
```

## Abstract

This document proposes deploying three new operations for [Tapscript][tapscript-bip]:
[BIP 446 `OP_TEMPLATEHASH`][templatehash-bip], [BIP 348 `OP_CHECKSIGFROMSTACK`][csfs-bip], and [BIP 349 `OP_INTERNALKEY`][internalkey-bip].

These minimal operations introduce modular functionalities which improve existing second layer protocols and make new
ones possible through plausible interactivity requirements.

## Motivation

The three proposed operations are simple, well-understood, and enable powerful new capabilities while minimizing the
risk of surprising behavior or unintended applications. They improve existing, well-studied protocols and make promising
new ones possible.

`OP_TEMPLATEHASH` allows a Tapscript to commit to the exact transaction that must spend it. This capability is a common
building block for second-layer protocols that is emulated today by requiring a signature from all involved parties.
Using `OP_TEMPLATEHASH` instead reduces interactivity, making such protocols simpler, safer, and sometimes significantly
more efficient.

`OP_CHECKSIGFROMSTACK` introduces [BIP 340][schnorr-bip] signature verification for arbitrary messages, which enables
delegation and oracle attestations.

Together, these features enable rebindable transaction signatures, making possible a new type of payment channel:
[LN-Symmetry ("Eltoo")][optech-eltoo]. Its simplicity makes advanced constructs like multiparty channels practical,
enables simplifications for 2-party channels such as [Daric][daric-channels], and can substantially improve
[statechains][statechains-optech]. Rebindable signatures also enable further interactivity reduction in second layer
protocols, as illustrated by the Ark variant "[Erk][ark-erk]" or the [dramatic simplification][greg-rebindable-ptlcs]
they bring to upgrading today's Lightning to [Point Time Locked Contracts][optech-ptlcs].

`OP_INTERNALKEY` allows to push the [Taproot][taproot-bip] internal key on the stack. This is a natural and extremely
simple optimisation for rebindable signatures.

## Specification

In [BIP 342 Tapscript](bip-0342.mediawiki), the following operations are updated. `OP_TEMPLATEHASH` redefines `OP_SUCCESS206` (0xce) as per
the specification of [BIP 446][templatehash-bip]. `OP_CHECKSIGFROMSTACK` redefines `OP_SUCCESS204` (0xcc) as per the
specification of [BIP 348][csfs-bip]. `OP_INTERNALKEY` redefines `OP_SUCCESS203` (0xcb) as per the specification of [BIP
349][internalkey-bip].

### Deployment

The specific activation is left to be determined at a later date.

## Rationale

This proposal seeks to extend Bitcoin's scripting capabilities in areas that are useful to proven approaches to scaling
Bitcoin payments. The operations proposed to achieve
these capabilities are contained within the more modern and well-studied Tapscript context. They are simple, composable
and unlikely to be made obsolete by future extensions to Bitcoin Script. They build upon existing operations and
therefore present a minimal cost to validation and implementation complexity.

More modular operations (such as [BIP 346][txhash-bip]) also enable these capabilities, and more. However they come with
an increased risk surface, notably in terms of implementation complexity. As the additional capabilities have not been
demonstrated to enable new important use cases or substantially improve existing ones beyond this proposal, we favour
the minimal approach.

An alternative to [BIP 446 `OP_TEMPLATEHASH`][templatehash-bip] is [BIP 119 `OP_CHECKTEMPLATEVERIFY`][ctv-bip]. This
proposal favours the minimal approach of [BIP 446 `OP_TEMPLATEHASH`][templatehash-bip] that does not modify legacy
scripting contexts and reuses the existing Taproot signature hashes. See [the rationale section of BIP
446][templatehash-rationale] for more details.

## Backward compatibility

This document proposes to give meaning to three Tapscript `OP_SUCCESS` operations. The presence of an `OP_SUCCESS` in a
Tapscript would previously make it unconditionally succeed. This proposal therefore only tightens the block validation
rules: there is no block that is valid under the rules proposed in this BIP but not under the existing Bitcoin consensus
rules. As a consequence these changes are backward-compatible with non-upgraded node software. That said, the authors
strongly encourage node operators to upgrade in order to fully validate all consensus rules.

## Acknowledgements

This proposal is similar to the combination of opcodes Brandon Black previously
[proposed](https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376) for activation under the name "LNHANCE".

## Copyright

This document is licensed under the Creative Commons CC0 1.0 Universal license.

[templatehash-bip]: bip-0446.md
[templatehash-rationale]: bip-0446.md#rationale
[ctv-bip]: bip-0119.mediawiki
[csfs-bip]: bip-0348.md
[internalkey-bip]: bip-0349.md
[schnorr-bip]: bip-0340.mediawiki
[taproot-bip]: bip-0341.mediawiki
[tapscript-bip]: bip-0342.mediawiki
[optech-eltoo]: https://bitcoinops.org/en/topics/eltoo
[optech-ptlcs]: https://bitcoinops.org/en/topics/ptlc
[txhash-bip]: bip-0346.md
[ark-erk]: https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
[greg-rebindable-ptlcs]: https://gist.github.com/instagibbs/1d02d0251640c250ceea1c66665ec163
[daric-channels]: https://eprint.iacr.org/2022/1295
[statechains-optech]: https://bitcoinops.org/en/topics/statechains/