BIP 433: Pay to Anchor (P2A)
In plain English: Defines Pay to Anchor, a tiny standard output that anyone can spend without a signature. Its purpose is to act as a hook for fee-bumping: by spending it in a follow-up transaction, any party can add fees to get a stuck transaction confirmed, which is useful for Lightning and similar protocols.
- Status
- Draft
- Type
- Informational
- Layer
- Applications
- Authors
- Gregory Sanders
- Assigned
- Last changed
- Topics
- Signatures, Transactions
- Source
- bip-0433.mediawiki on GitHub · Markdown
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 type.
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 CPFP fee bumping later, when prevailing feerates for block inclusion are better known.
When the wallet user is unconcerned by *who* is able to bump the transaction fees as long as someone does, this output type may confer a couple of advantages:
1. Using an output type with minimal output and spending input footprint saves fees 2. Keyless operation aids in interoperability of services like watchtowers as there is no privileged key material required for bumping
with the drawback that selection of this output type could result in griefing if anti-pinning measures are not taken. If unsure, use in conjunction with TRUC transactions.
Specification
A P2A output is defined as one with the scriptPubKey
OP_1 <0x4e73>[1]
corresponding to the addresses bc1pfeessrawgf on Bitcoin mainnet, tb1pfees9rn5nz on public testnets, and bcrt1pfeesnyr2tx on regtest.
P2A inputs are considered standard by Bitcoin Core for spending if no witness data is attached. This avoids meaningless witness padding. Consensus meaning is unchanged.
Implementation
Related Work
There are a number of related but separate historical concepts:
Ephemeral Dust: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust threshold for P2A is set at 240 satoshis by default, other dust levels remain unchanged, and the dust-having transaction must be zero fee. Any output script type may have down to 0-value outputs.
Ephemeral Anchors: Historically the union of P2A output type and ephemeral dust. Keyed anchors along with ephemeral dust are also an accepted pattern and as such they remain separate concepts.
TRUC transactions: TRUC transactions bound the topology including child transaction size, which aids in anti-pinning for the P2A output, as anyone can attach a child transaction including an oversized, low feerate one. There is no inherent dependency on this concept and P2A.
Backward Compatibility
Creation of P2A outputs has been considered standard since the deployment of Segwit softfork on the network.
Transactions with P2A inputs were previously nonstandard, reserved as an upgrade hook.
There are no known conflicts with previous usage.
Acknowledgements
Thanks to collaborators who helped focus the historical ideas into deployed ones: Suhas Daftuar, Gloria Zhao, Pieter Wuille, Jeremy Rubin, and Bastien Teinturier.
References and Rationale
- Native segwit outputs are composed of a witness version and a witness program. A witness program must be at least two bytes long and the specific bytes cannot be zeros. The two bytes for the P2A witness program are chosen to spell "fees" in bech32m encoding. ↩
Copyright
This document is licensed under the 3-clause BSD license.