Pay-to-Anchor (P2A)

What Is Pay-to-Anchor (P2A)?

Pay-to-Anchor (P2A) is a standardized Bitcoin output script type that anyone can spend without providing a signature or witness data. Defined in BIP 433 by Gregory Sanders, P2A creates the most compact possible hook for attaching a CPFP child transaction to bump the fee of a pre-signed parent.

The core problem P2A solves: pre-signed transactions like Lightning commitment transactions cannot predict what fee rate will be needed at the time they are broadcast. Fees may have been set weeks or months before the transaction needs to confirm. P2A provides a minimal output that either party (or any third party) can spend to create a child transaction that pays the appropriate fee for both parent and child.

P2A was standardized in Bitcoin Core 28.0 (October 2024) and represents a significant improvement over the previous anchor outputs design used in Lightning, reducing cost, complexity, and vulnerability to transaction pinning attacks.

How It Works

P2A uses a SegWit version 1 witness program with the smallest possible data push: two bytes. The output script is:

OP_1 <0x4e73>

The two bytes 0x4e73 were deliberately chosen because they spell "fees" when encoded as a bech32m address: bc1pfeessrawgf. Spending this output requires an empty witness: no signature, no public key, no script. This makes it the most compact anchor output possible.

The Fee-Bumping Flow

P2A is designed to work within a stack of complementary Bitcoin Core policy features:

1. A pre-signed transaction (such as a Lightning commitment transaction) uses TRUC (v3) transaction format, which allows the parent to pay zero fees
2. The transaction includes a P2A output at or below the dust limit (240 satoshis for P2A, or zero satoshis when using ephemeral dust rules)
3. When the transaction needs to be broadcast, either party creates a child transaction that spends the P2A output
4. The child carries enough fees for both itself and the parent
5. The parent and child are relayed together via 1P1C package relay, so miners evaluate the package fee rate rather than each transaction individually

Because P2A requires no key material to spend, the fee-bumping child can be created by either channel party, a watchtower, or even a third-party fee-bumping service. This is a major improvement over the old anchor outputs design, where only the respective channel party (or anyone after a 16-block delay) could spend each anchor.

Ephemeral Dust Integration

Bitcoin Core 29.0 (April 2025) introduced ephemeral dust rules that complement P2A. Under these rules, a zero-fee TRUC transaction is allowed to contain a single dust output (including a P2A output worth zero satoshis), provided that output is spent by another transaction in the same package. This combination is informally called an ephemeral anchor: the P2A output exists only long enough to relay the package and is consumed immediately by the CPFP child.

Script Details

P2A is technically a SegWit version 1 output, like Taproot (P2TR). However, while Taproot uses a 32-byte witness program (a public key), P2A uses only a 2-byte witness program. Per SegWit consensus rules, witness programs between 2 and 40 bytes are valid for any witness version, with the spending rules left to future soft forks. Since no soft fork has defined spending rules for 2-byte SegWit v1 programs, spending requires only an empty witness.

# P2A output script (4 bytes total)
# OP_1 = 0x51 (SegWit version 1)
# OP_PUSHBYTES_2 = 0x02
# Data = 0x4e73
scriptPubKey: 51024e73

# To spend: provide an empty witness
witness: <empty>

P2A vs. Old Anchor Outputs

The original anchor outputs mechanism (introduced in the Lightning specification in 2020) solved the same fundamental problem: allowing fee bumping of pre-signed commitment transactions. However, it came with significant drawbacks that P2A eliminates:

The old design required two anchors because each party needed their own keyed output to bump fees. This wasted block space and created pinning opportunities: a malicious counterparty could attach a large, low-feerate child to their anchor, blocking the honest party's fee bump. The CPFP carve-out rule mitigated this but was itself a special case with limitations. P2A sidesteps the entire problem through TRUC's topology restrictions, which limit each parent to a single unconfirmed child of at most 10,000 virtual bytes.

Use Cases

Lightning Network Commitment Transactions

The primary use case for P2A is Lightning Network commitment transactions. The Lightning specification (BOLTs #1228) defines a new "zero-fee commitment" format where the commitment transaction pays zero fees and includes a single shared P2A output capped at 240 satoshis. When either party needs to force-close the channel, they broadcast the commitment transaction and attach a CPFP child spending the P2A output with the current market fee rate.

This design decouples fee estimation from channel state updates entirely. Under the old model, commitment transactions needed to include a "reasonable" fee at signing time, which could be far too low (or wastefully high) by the time the transaction was actually broadcast.

Watchtower Fee Bumping

Because P2A outputs require no key material to spend, watchtowers can bump fees on behalf of channel participants without holding any private keys. A watchtower monitoring for revoked commitment transactions can broadcast the justice transaction and attach a fee-bumping child to the P2A output using its own funds. This improves security for mobile and offline users who delegate channel monitoring.

Pre-Signed Contract Protocols

Any protocol that relies on pre-signed transactions benefits from P2A. This includes discreet log contracts (DLCs), vaults, coinjoins with time-locked outputs, and other smart contract constructions on Bitcoin. By adding a P2A output to pre-signed transactions, participants ensure they can always get transactions confirmed regardless of future fee market conditions.

Adoption Status

P2A support has been rolling out across the Bitcoin and Lightning ecosystem:

• Bitcoin Core 28.0 (October 2024) standardized P2A output spending and introduced TRUC transactions
• Bitcoin Core 29.0 (April 2025) added ephemeral dust rules, completing the full ephemeral anchor stack
• Eclair v0.14.0 shipped production support for zero-fee commitment channels with P2A, taproot channels, and splicing
• LDK promoted zero-fee commitment channels (using a shared P2A output) from experimental to a production feature
• LND and Core Lightning have ongoing implementation work, with LND tracking P2A and ephemeral dust awareness in its fee-bumping logic

The Lightning specification (BOLTs #1228) formalizing zero-fee commitments with P2A has been merged, providing a common standard that all implementations are converging on. For a deeper look at how these policy changes affect Lightning, see the research article on v3 transactions and package relay in Lightning.

Relationship to Cluster Mempool

P2A and TRUC transactions were designed to be forward-compatible with cluster mempool, a major refactor of Bitcoin Core's mempool data structures. Cluster mempool (merged in late 2025) provides a more general framework for evaluating transaction packages by fee rate, which naturally supports the P2A + CPFP pattern.

Under the old mempool architecture, special-case rules like CPFP carve-out were needed to handle anchor output spending. TRUC transactions serve as a bridge: they provide pinning protection today through topology restrictions, while cluster mempool will eventually enable more flexible package evaluation that makes some of these restrictions unnecessary. For more details, see the cluster mempool explainer.

Risks and Considerations

Third-Party Fee Griefing

Because P2A outputs are anyone-can-spend, a malicious third party could race to spend the P2A output with a low-fee child, potentially blocking the legitimate party's fee bump. However, TRUC rules mitigate this significantly: only one unconfirmed child is allowed per TRUC parent, and replace-by-fee (RBF) can be used to replace a low-fee child with a higher-fee one. The attacker would need to continuously outbid the honest party, making sustained griefing expensive.

Trimmed HTLC Value

In Lightning commitment transactions using P2A, the value of trimmed HTLCs (those too small to justify on-chain settlement) goes to miners via the fee-bumping child rather than remaining with the channel parties. This is a design trade-off: trimmed HTLCs were always miner-extractable value in the old anchor design too, but the P2A mechanism makes it more explicit.

UTXO Set Impact

A P2A output that is not spent (for example, if a commitment transaction confirms without a CPFP child) adds a small entry to the UTXO set. However, the ephemeral dust rules are designed to prevent this: a zero-satoshi P2A output must be spent in the same package to be relayed, ensuring it never enters the UTXO set alone. For non-zero P2A outputs, the value is low enough (240 sats maximum) that economic incentives discourage leaving them unspent.

Requires Updated Node Software

The full P2A workflow requires Bitcoin Core 28.0 or later for P2A spending standardization and TRUC support, and 29.0 or later for ephemeral dust. Nodes running older versions will not relay these transactions, so sufficient network upgrade is needed for reliable propagation. As of 2026, adoption of Bitcoin Core 28.0+ is widespread enough that P2A transactions propagate reliably across the network.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.