Home › Browse › BIP 448

BIP 448: Taproot-native (Re)bindable Transactions

In plain English: Bundles three small script instructions, OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK and OP_INTERNALKEY, into a single proposed upgrade. Together they would let transactions commit to specific future spends or be re-bound to new ones, improving Lightning and enabling other second-layer protocols.

Status
Draft
Type
Specification
Layer
Consensus (soft fork)
Authors
Gregory Sanders, Antoine Poinsot, Steven Roose
Assigned
Last changed
Topics
Taproot, Consensus, Transactions
Source
bip-0448.md on GitHub · Markdown

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".

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

Related proposals

  • BIP 11: M-of-N Standard Transactions: Deployed. Made "M-of-N" transactions, which require any M signatures out of N possible keys, a standard type that nodes relay. This enabled shared-control arrangements such as escrow or wallets needing two of…
  • BIP 12: OP_EVAL: Closed. Proposed a new script command, OP_EVAL, that would let the receiver of coins define the conditions for spending them instead of the sender. It was abandoned over security concerns and replaced by…
  • BIP 16: Pay to Script Hash: Deployed. Introduced Pay to Script Hash (P2SH), letting a sender pay to a short fingerprint of spending rules that the recipient reveals only when spending. This shifted the cost and complexity of setups like…
  • BIP 30: Duplicate transactions: Deployed. Added a rule forbidding a block from including a transaction with the same ID as an earlier one whose outputs are not fully spent. Such duplicates can overwrite earlier coins and make them…
  • BIP 31: Pong message: Deployed. Adds a "pong" reply that a node sends back when it receives a "ping" containing a random number. This lets software reliably tell whether a connection to another node is still alive.
  • BIP 34: Block v2, Height in Coinbase: Deployed. Upgraded blocks to version 2 and required each block's coinbase transaction (the one paying the miner) to include the block's height. This makes every coinbase unique, preventing duplicate…