349 - OP_INTERNALKEY
BIP: 349 source Layer: Consensus (soft fork) Title: OP_INTERNALKEY Authors: Brandon Black Jeremy Rubin Status: Draft Type: Specification Assigned: 2024-11-14 License: BSD-3-Clause Abstract This BIP describes a new tapscript opcode (OP_INTERNALKEY) which pushes the taproot internal key to the stack. Specification When verifying taproot script path spends having leaf version 0xc0 (as defined in BIP 342), OP_INTERNALKEY replaces OP_SUCCESS203 (0xcb). OP_INTERNALKEY pushes the 32-byte x-only representation of the taproot internal key (referred to as p), as defined in BIP 341, to the stack. Motivation Key spend with additional conditions When building taproot outputs, especially those secured by an aggregate key representing more than one signer, the parties may wish to collaborate on signing with the taproot internal key, but only with additional script restrictions. In this case, OP_INTERNALKEY saves 8 vBytes. Mitigated control block overhead for scripts using ha...
348 - CHECKSIGFROMSTACK
BIP: 348 source Layer: Consensus (soft fork) Title: CHECKSIGFROMSTACK Authors: Brandon Black Jeremy Rubin Status: Draft Type: Specification Assigned: 2024-11-26 License: BSD-3-Clause Abstract This BIP describes a new opcode for the purpose of checking cryptographic signatures in bitcoin scripts against data from the stack. Summary When verifying taproot script spends having leaf version 0xc0 (as defined in BIP 342), we propose OP_CHECKSIGFROMSTACK to replace OP_SUCCESS204 (0xcc). OP_CHECKSIGFROMSTACK has semantics similar to OP_CHECKSIG, as specified below. Briefly, it pops 3 elements from the stack: a 32-byte public key, a message, and a signature. If the signature is valid for that public key and message, 1 is pushed to the stack. If the signature is the empty vector, 0 is pushed to the stack, and otherwise script execution fails. Only 32-byte keys are constrained. Similar to BIP 342 unknown key types, for other key lengths no signature verification is perfo...
433 - Pay to Anchor (P2A)
BIP: 433 source Layer: Applications Title: Pay to Anchor (P2A) Authors: Gregory Sanders Status: Draft Type: Informational Assigned: 2025-12-08 License: BSD-3-Clause Discussion: 2024-06-27: https://github.com/bitcoin/bitcoin/pull/30352 Github PR 2024-10-10: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/ wallet integration guide Table of ContentsAbstractMotivationSpecificationImplementationRelated WorkBackward CompatibilityAcknowledgementsReferences and Rationale Abstract This document describes a new standard output script called Pay to Anchor (P2A) and prescribes making spending of this output type standard. This output is "keyless" meaning no signature or witness data at all are required to spend this output typea. Motivation The "anchor" output type is a commonly used pattern in Bitcoin layer 2 systems such as Lightning Network and beyond. This pattern allows transactions which are presigned far in advance to leave a "hook" for CPF...
119 - CHECKTEMPLATEVERIFY
BIP: 119 source Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY Authors: Jeremy Rubin Status: Draft Type: Specification Assigned: 2020-01-06 License: BSD-3-Clause Table of ContentsAbstractSummaryMotivationDetailed SpecificationDeploymentReference ImplementationRationaleThe DefaultCheckTemplateVerifyHash of the transaction at the current input index matches the top of the stackCommitting to the version and locktimeCommitting to the ScriptSigs HashCommitting to the number of inputsCommitting to the Sequences HashCommitting to the Number of OutputsCommitting to the outputs hashCommitting to the current input's indexCommitting to Values by HashUsing SHA256Using Non-Tagged HashesThe Ordering of FieldsDesign Tradeoffs and RisksDenial of Service and Validation CostsPermanently Unspendable OutputsForwarding AddressesNOP-Default and Recommended Standardness RulesFeature RedundancyFuture UpgradesCHECKTEMPLATEVERIFY VersionsOP_CHECKSIGFROMSTACKVERIFYOP_AMOUNTVERIFYOP_CAT/OP...