Add P2A BIP #1982

instagibbs · 2025-09-24T15:40:51Z

For interoperability with other schemes, it behooves me to write a BIP for this output type. It's already standard to spend in well over half the network.

h/t roasbeef for bothering me about this repeatedly

jonatack

Quick first pass.

jonatack · 2025-09-25T21:13:48Z

bip-paytoanchor.mediawiki

+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 on average
+2. Keyless operation aids in interoperability of services like watchtowers as there is no privelaged key material for bumping


Suggested change

2. Keyless operation aids in interoperability of services like watchtowers as there is no privelaged key material for bumping

2. Keyless operation aids in interoperability of services like watchtowers, as there is no privileged key material for bumping,

jonatack · 2025-09-25T21:21:30Z

bip-paytoanchor.mediawiki

+
+There are a number of related but separate historical concepts:
+
+[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.


Suggested change

[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.

[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, other dust levels remain unchanged, and the dust-having transaction must be zero fee.

jonatack · 2025-09-25T21:24:19Z

bip-paytoanchor.mediawiki

+
+A P2A output is defined as one with the exact witness output script
+
+<code>OP_1 <0x4e73></code>


Perhaps add a footnote describing "what is the 0x4e73 for?" per your answer in bitcoin/bitcoin#30352 (comment)

jonatack · 2025-09-25T21:30:45Z

bip-paytoanchor.mediawiki

+Jeremy Rubin,
+and Bastien Teinturier.
+
+==References and Rationale==


TBD, or remove this header?

one is added, leaving

jonatack · 2025-09-25T21:33:04Z

bip-paytoanchor.mediawiki

+
+====Backward Compatibility====
+
+Creation of P2A outputs has been considered standard since the deployment of Segwit softfork on the network.


Maybe link here to the SegWit BIP section making them standard.

the BIPs aren't standardness BIPs, so I'm not sure that helps.

Roasbeef

Thanks for making this. Nearly done with an implementation for btcsuite.

Roasbeef · 2025-09-25T23:28:28Z

bip-paytoanchor.mediawiki

+1. Using an output type with minimal output and spending input footprint saves fees on average
+2. Keyless operation aids in interoperability of services like watchtowers as there is no privelaged key material for bumping
+
+with the drawback that selection of this output type could result in griefing if anti-pinning measures are not taken.


Recommend that if unsure, then this new type is best used w/ v3 transactions are they have stricter replacement rules?

Roasbeef · 2025-09-25T23:30:18Z

bip-paytoanchor.mediawiki

+
+There are a number of related but separate historical concepts:
+
+[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.


I think it's also worth specifying above that P2A outputs can be zero value as well.

Roasbeef · 2025-09-25T23:31:14Z

bip-paytoanchor.mediawiki

+
+There are a number of related but separate historical concepts:
+
+[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.


Have you considered making this BIP slightly more generalized, and also preicelyf defining the acceptance rules for ephemerl dust?

Eg: one question that's popped into my mind several times is: can ephemeral dust only be used with v3 transactions?

Ephemeral dust ended up being very implementation-specific, and likely to change in some future.

Wondering if there is a more BOLT-like living document suitable for that.

Roasbeef · 2025-09-25T23:35:06Z

bip-paytoanchor.mediawiki

+
+<code>OP_1 <0x4e73></code>
+
+corresponding to the address <code>bc1pfeessrawgf</code> on Bitcoin mainnet.


Should also specify the encoding for: regtest, signet, and testnet. Would make for good test vectors.

Roasbeef · 2025-09-25T23:36:45Z

bip-paytoanchor.mediawiki

+
+There are a number of related but separate historical concepts:
+
+[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.


Dust threshold instead of just dust?

As in, values before 240 for P2A are considered dust.

Roasbeef · 2025-09-25T23:40:29Z

bip-paytoanchor.mediawiki

+Jeremy Rubin,
+and Bastien Teinturier.
+
+==References and Rationale==


Should link to the bitcoind PR that implemented this.

bitcoin/bitcoin#30352

Was in "Implementation" section

jonatack added the New BIP label Sep 24, 2025

jonatack reviewed Sep 25, 2025

View reviewed changes

Roasbeef reviewed Sep 25, 2025

View reviewed changes

Add P2A BIP

9ed387c

instagibbs force-pushed the 2025-09-p2a branch from 3451560 to 9ed387c Compare October 7, 2025 14:47

	2. Keyless operation aids in interoperability of services like watchtowers as there is no privelaged key material for bumping
	2. Keyless operation aids in interoperability of services like watchtowers, as there is no privileged key material for bumping,


		There are a number of related but separate historical concepts:

		[https://github.com/bitcoin/bitcoin/pull/30239 Ephemeral Dust]: Relay policies allowing a single dust output as long as it is spent in a transaction package. As an implementation detail, dust for P2A is set at 240 satoshis by default, others dust levels remain unchanged, and the dust-having transaction must be zero fee.


		A P2A output is defined as one with the exact witness output script

		<code>OP_1 <0x4e73></code>


		====Backward Compatibility====

		Creation of P2A outputs has been considered standard since the deployment of Segwit softfork on the network.


		<code>OP_1 <0x4e73></code>

		corresponding to the address <code>bc1pfeessrawgf</code> on Bitcoin mainnet.

Add P2A BIP #1982

Are you sure you want to change the base?

Add P2A BIP #1982

Conversation

instagibbs commented Sep 24, 2025

Uh oh!

jonatack left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Roasbeef left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants