BIP 448: Taproot-native (Re)bindable Transactions

  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: BIP 446 OP_TEMPLATEHASH, BIP 348 OP_CHECKSIGFROMSTACK, and BIP 349 OP_INTERNALKEY.

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 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"). Its simplicity makes advanced constructs like multiparty channels practical, enables simplifications for 2-party channels such as Daric, and can substantially improve statechains. Rebindable signatures also enable further interactivity reduction in second layer protocols, as illustrated by the Ark variant "Erk" or the dramatic simplification they bring to upgrading today's Lightning to Point Time Locked Contracts.

OP_INTERNALKEY allows to push the Taproot internal key on the stack. This is a natural and extremely simple optimisation for rebindable signatures.

Specification

In BIP 342 Tapscript, the following operations are updated. OP_TEMPLATEHASH redefines OP_SUCCESS206 (0xce) as per the specification of BIP 446. OP_CHECKSIGFROMSTACK redefines OP_SUCCESS204 (0xcc) as per the specification of BIP 348. OP_INTERNALKEY redefines OP_SUCCESS203 (0xcb) as per the specification of BIP 349.

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) 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 is BIP 119 OP_CHECKTEMPLATEVERIFY. This proposal favours the minimal approach of BIP 446 OP_TEMPLATEHASH that does not modify legacy scripting contexts and reuses the existing Taproot signature hashes. See the rationale section of BIP 446 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 for activation under the name "LNHANCE".

Copyright

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