Ephemeral Dust

[instagibbs]

Opening to allow discussion on the text separately from the Bitcoin Core implementation here bitcoin/bitcoin#30239

Example usage:
https://github.com/instagibbs/bolts/commits/zero_fee_commitment
https://github.com/instagibbs/lightning/commits/commit_zero_fees

[instagibbs]

@ariard bring comment from instagibbs/bolts@4830650#diff-6bed824879b760d329ec379b16a1d0e78ffba034fdfa13b95cf0480e09fa7c4bR156

This is uncertain to me how this rule works with trimmed HTLCs on LN commitment transactions making their fees non-zero, even assuming anchor outputs where second-stage txn are signed with 0-feerate.

I gave an example spec at the top, and implementation(of most of it) for CLN. Links again here:

Example usage:
https://github.com/instagibbs/bolts/commits/zero_fee_commitment
https://github.com/instagibbs/lightning/commits/commit_zero_fees

TLDR: trimmed value can go into the anchor itself, and is simply spent to fees by the spender.

Otherwise a time-sensitive package can be tampered by third-parties entering into replacement cycling games, without being a direct off-chain counterparty to the target transaction traffic.

In the BIP I can mention that it allows any party to spend, therefore any party can attempt a cycling attack. We're not going to agree on the severity of the attack, so it's up to implementer to do their own research.

[ariard]

TLDR: trimmed value can go into the anchor itself, and is simply spent to fees by the spender.

I believe this is broken - Let’s say you have Alice and Bob sharing a Lightning channel, with max_accepted_htlcs (483) on both sides. Alice is a routing hop allowing HTLC forward going through Alice-Bob link. Bob circularly routes 483 offered HTLCs of value 330 satoshis (total amount 159390 satoshis). Those HTLCs are symmetrically committed on both Alice and Bob states. Assuming Bob can broadcast privately to a transaction accelerator with a child pocketing the anchor itself, Bob can mine the commitment transaction and steals 159390 satoshis from Alice’s balance.

Thanks to correct me if my understanding of option_commit_zero_fee is incorrect.

As of today, Bob could do the same attack by routing the HTLCs, however as the trimmed HTLCs are committed as miner fees, if Bob does not have low-hashrate capabilities, he cannot steal from Alice. Moving trimmed HTLC amounts from miners fees to a anyone-can-spend amount changes notably the threat model, in my opinion.

In the BIP I can mention that it allows any party to spend, therefore any party can attempt a cycling attack. We're not going > to agree on the severity of the attack, so it's up to implementer to do their own research.

While I agree that we won’t agree on the severity of a replacement cycling attack, I disagree on the deference to put on implementers the responsibility to do their own research on the security of such proposal. Not only this is unfavorable practice for Internet protocol standardization works (all IETF RFCs must have mandatory security sections - RFC 3552), beyond for the given proposal it modifies the attacker incentives model as anyone on the peer-to-peer transaction-relay network can enter into replacement cycling attacks against your time-sensitive packages or massive transaction batch.

Allowing anyone to tamper with packages is not only an issue for the safety of your use-case funds, it does open the door to adversaries tamper with the global transaction traffic, with potential way to realize gains. In the past, miners-harvesting attacks have been considered, and here it’s opening one. If you know that the transaction issuer of this transaction pattern will automatically fee-bump its package after X blocks without confirmation, anyone-can-spend ephemeral anchor allows you to substitute a “honest” CPFP at 20 sat/vbytes with a “malicious" CPFP at 30 sat/vbytes and then evicts this CPFP to trigger an eviction of the 0-fee parent itself from network mempools.

For this last reason, I think that anyone-can-spend ephemeral anchor should be reconsidered and locking the ephemeral anchor under a counterparty pubkey should be introduced, as we’re doing with anchor outputs on lightning commitment transactions today. I understand the efficiency reasons to use an OP_TRUE though I’m unsure it’s worth the newly introduced safety weaknesses.

[luke-jr]

Node policy is not a standardizable subject matter in itself, and I'm not really seeing anything here to standardize?

[instagibbs]

As of today, Bob could do the same attack by routing the HTLCs, however as the trimmed HTLCs are committed as miner fees, if Bob does not have low-hashrate capabilities, he cannot steal from Alice. Moving trimmed HTLC amounts from miners fees to a anyone-can-spend amount changes notably the threat model, in my opinion.

@ariard it's an implementation detail for both Bitcoin Core and LN spec, but your hesitancy has caused me to look for a better solution than I was previously thinking: https://delvingbitcoin.org/t/ephemeral-anchors-and-mev/383

While I agree that we won’t agree on the severity of a replacement cycling attack

I'm fine adding some warning text wherever to inform implementors. Propose some please.

For this last reason, I think that anyone-can-spend ephemeral anchor should be reconsidered and locking the ephemeral anchor under a counterparty pubkey should be introduced, as we’re doing with anchor outputs on lightning commitment transactions today. I understand the efficiency reasons to use an OP_TRUE though I’m unsure it’s worth the newly introduced safety weaknesses.

I think the story for keyless is much simpler, even if you personally disagree with the relative security of it.

Anything that's relay-standard now would be a potential "rug" if it suddenly required you to be V3, that you must RBF all sibling spends, etc. If we instituted a rule anyways safely somehow, it may interfere with future relaxations where we don't care about dust(say, widespread utreexo deployment). Regardless today it also has a weaker anti-dust story as it can't be cleaned up except by key owners.

We're just not going to agree on this given our nearly year long discussions of cycle replacement attacks and similar, and it'll be up to others to weigh in on this point for specific use-cases. I apologize for not moving forward with this line of discussion from here on out.

[instagibbs]

Node policy is not a standardizable subject matter in itself, and I'm not really seeing anything here to standardize?

I'll let others weigh in, but in general I'd like to have a common place to have a tx format, like this, publicly documented, with some suggestions for implementors, even if we cannot force anyone to do so.

Related, I see no mention of banning policy in BIP rules; let me know if I missed something.

I'll leave this PR open for now.

[luke-jr]

BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.

[darosior]

I'll let others weigh in

For what it's worth i think ti's useful to have a BIP for this.

BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.

By this same token why bother writing BIPs for output script descriptors? For deterministic key generation? It's most of the time an individual decision whether to use a feature. But that doesn't change the fact that it's useful to have a public, implementation-agnostic, documentation for anything where inter-compatibility is needed.

[ajtowns]

The main policy change is making the script standard to create as an ouput. I think it's only that you're defining a new valid witness program (rather than using OP_TRUE directly) that means you also need to make spending standard.

[ajtowns]

Might want to emphasise here that dust limits do not apply?

[ajtowns]

Does this mean the bitcoin core PR should (does?) reject attempts to prioritisetransaction when it notices the tx being prioritised creates an EA output?

[glozow]

IIRC an older implementation had this

[ajtowns]

Mixes MUST and should; these are all relay policies, so shouldn't they all be at the same level of compulsion?

Arguably it may be attractive for miners to stuff witness data in here -- if they want to include modest amounts of arbitrary data in a block, then doing it in the witness is cheaper than anywhere else, and if someone else is paying for the tx that's associated with the witness, that's cheaper than them creating a dummy tx themselves.

[michaelfolkson]

BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.

I suspect if this is a non-negotiable for this repo and this BIP editor (and hence won't get a BIP number) then we'll need a bips-policy repo or something (under the same GitHub organization perhaps). I get Luke's perspective to some extent (default policy proposals are certainly a very different animal to say consensus rule proposals) but this shouldn't be stunting collaboration between Core developers and Lightning developers on policy proposals. Personally I'd rather these draft proposals were incorporated into the BIP process but if that isn't going to happen then the documents need to be worked on in a different repo and with a different numbering system. Of course there is no guarantee these policy proposals will ever be merged into Core or an alternative implementation (they'd need to go through the Core etc review process to be merged) but that doesn't mean people can't draft and collaborate on proposals. Applies to #1541 too.

[glozow]

The idea of only using BIPs for standards that need to be adopted by "everybody" or are consensus rules has no precedent and makes no sense. There are lots of wallet standards, p2p messages, and services dedicated to SPV clients that are used by a small fraction of Bitcoin users and software. A large number of BIPs are not relevant to node software, but they are Bitcoin-specific and should have canonical implementation-agnostic specifications and documentation for multiple people to refer to.

[michaelfolkson]

@glozow: I personally agree with you. I asked Luke about this on X/Twitter (it is public so I hope he doesn't mind me copying it over here) and he responded:

"Transaction pinning" AFAIK is a result of policy centralization efforts, not a real problem. The alternative is to encourage diverse policies, and at the technical level, to prepare multiple alternative transaction variants to ensure one being rejected won't be a problem.

So his perspective is not that BIPs need to be adopted by everybody or have to be consensus rules (as you state) but that he thinks attempts to standardize policy aren't a good idea and are perhaps even harmful. Again I personally disagree with that perspective (and I suspect everyone working on these proposals also disagree with that perspective) but just clarifying what Luke's perspective is.

[michaelfolkson]

I suspect if this is a non-negotiable for this repo and this BIP editor (and hence won't get a BIP number) then we'll need a bips-policy repo or something (under the same GitHub organization perhaps).

In the absence of convincing Luke otherwise or adding a new BIP editor who disagrees directly with Luke on this topic it seems to me like a new repo for policy related BIPs is the best way forward.

[jonatack]

Suggested change

	Type: Standards Track
	Type: Informational

Perhaps "Informational" rather than "Standards Track", as policy is an individual, per-node decision, but it may be helpful to document policy R&D as informational BIPs.

[instagibbs]

done

[jonatack]

Note that this isn't one of the BIP123 / BIP2 classification layers. I'm not sure, but it looks like BIPs 2 and 123 would need to be updated if there is consensus on classifying BIPs as Mempool Policy layer.

[ajtowns]

BIP 125 (RBF) uses "Layer: Application" here. Having a standard here is pretty much about coordination between node behaviour ("this sort of tx will be relayed") and applications ("how do i make txs that will be relayed?") so that seems reasonable?

[instagibbs]

did @ajtowns suggestion for now

[instagibbs]

pushed fixups, but marking as draft until I come back to this. Scope has changed substantially so this essentially needs a complete re-write.

short motivation for changes for those interested here: bitcoin/bitcoin#29001 (comment)

[glozow]

jw are you planning to update this since n30239 is open?

[glozow]

IIRC an older implementation had this

[glozow]

Needs update for TRUC / BIP 431 across doc

[instagibbs]

@glozow yes thanks for reminding me, a number of things have changed like the output format requirements, sibling eviction being broken out into its own TRUC feature, etc.

I'll revive this this week

[murchandamus]

Did another pass, looks pretty good to me. I noticed that there is no Rationale section, although that seems to be somewhat covered in motivation and related works. If you wanted to add more explanation to design decisions, it might make sense to add such a section.

[murchandamus]

Suggested change

	Ephemeral Anchors are a mempool policy carve-out that allows any value utxos,
	Ephemeral Anchors are a mempool policy carve-out that allows UTXOs of any value,

[murchandamus]

Previously plural:

Suggested change

	even 0-value dust, to be created, provided it is also spent within the same
	even 0-value dust, to be created, provided they are also spent within the same

[murchandamus]

Switching tenses:

Suggested change

	Relay dust limits have been in place in most implementations of the Bitcoin
	protocol to discourage the creation of UTXOs that are never spent in the future,
	bloating the UTXO set and increasing the validation burden for validating
	nodes.
	Relay dust limits have been in place in most implementations of the Bitcoin
	protocol to discourage the creation of UTXOs that are never spent in the future,
	bloat the UTXO set, and increase the validation burden for validating
	nodes.

[murchandamus]

What do you think about:

Suggested change

	[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
	allows a small amount of contract value to be given to an output to merely allow network relay
	by avoiding dust checks, but not as the primary source of fee funds. Instead the child transaction
	spending the anchor is given the responsibility of bringing funds.
	[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
	allows a small amount of contract value to be given to an output to allow network relay
	by passing dust checks, but not as the primary source of fee funds. Instead, the child transaction
	spending the anchor is responsible for providing the funds.

[murchandamus]

"requiring dust values" ⇒ Isn’t the issue that they must have above dust amounts?

How about:

Suggested change

	It is cleaner for this abstraction and others if instead of requiring
	dust values in anchors, the anchor itself can be 0 value.
	In this and similar abstractions it would be cleaner if the anchor itself could be 0-value
	instead of requiring anchors to exceed dust amounts.

[murchandamus]

Suggested change

	* Have the dust value spent in the same TRUC cluster
	* Have its emphemeral anchor spent in the same TRUC cluster

[murchandamus]

Perhaps:

Suggested change

	If included in an otherwise valid block, these additional constraints do not apply
	as this is a policy-only change.
	These constraints apply only to mempool policy. Otherwise valid blocks are not
	invalidated by breaking these policy-only rules as they have no bearing on consensus.

[murchandamus]

Suggested change

	and insightful feedback(in last name order):
	and insightful feedback (in last name order):

Or maybe:

Suggested change

	and insightful feedback(in last name order):
	and insightful feedback (ordered by last name):

[murchandamus]

Since it is one drawback shared by all of these proposals, ISTM that it should just be "drawback" instead of "drawbacks".

Suggested change

[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021334.html SIGHASH_GROUP] style proposals are an alternative method of bringing funds to a transaction without involving CPFP by enacting a softfork. Making these pin-resistant may require follow-on policy work, or [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html more general covenants] to directly stop pins we want to avoid. The drawbacks of these are the necessity of a softfork.

[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021334.html SIGHASH_GROUP] style proposals are an alternative method of bringing funds to a transaction without involving CPFP by enacting a softfork. Making these pin-resistant may require follow-on policy work, or [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020458.html more general covenants] to directly stop pins we want to avoid. The drawback of these are the necessity of a softfork.

[murchandamus]

Suggested change

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

[instagibbs]

updated taking or adapting all suggestions and added a small rationale section

[murchandamus]

Changes look good to me, found a few typos

ACK 8852274

[murchandamus]

Suggested change

	spending the anchor is responsibile for providing the funds.
	spending the anchor is responsible for providing the funds.

[murchandamus]

Suggested change

	1. The ephemeral anchor transaciton should be 0-fee itself
	1. The ephemeral anchor transaction should be 0-fee itself

[murchandamus]

Suggested change

	spending the acnhor. TRUC transaction restrictions inherently follow the single
	spending the anchor. TRUC transaction restrictions inherently follow the single

[murchandamus]

Suggested change

	and basic package relay, users can generate and propogate 0-fee transactions provided
	and basic package relay, users can generate and propagate 0-fee transactions provided

[murchandamus]

Suggested change

	1. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the the user's need for lack of txid malleability. Further policy
	1. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the user's need for lack of txid malleability. Further policy

[murchandamus]

Suggested change

	The discussion lacked a solution to the issue of the dust entering into the utxo set
	The discussion lacked a solution to the issue of the dust entering into the UTXO set

[instagibbs]

fixed typos, thanks

[murchandamus]

Re-ack 9e463fe via Range-Diff

[murchandamus]

Let’s call this BIP 432

[petertodd]

"Be an otherwise valid TRUC transaction adhering to the corresponding topological constraints"

What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.

[luke-jr]

Let’s call this BIP 432

It's still not BIP material, thus not eligible for assignment or acceptance

[reardencode]

Good start for TRUC-ephemeral anchor, looking forward to OP_TRUE and/or OP_1 0x4e73 anchors.

I learned from this transaction that paying to short segwit v1 addresses is already standard, so it's a smaller change than I had realized to standardize short witness ephemeral anchors.

[reardencode]

Suggested change

	1. Keyed anchor: A key, possibly shared by multiple privileged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
	output type that allows key material.
	1. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the user's need for lack of txid malleability. Further policy
	extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
	# Keyed anchor: A key, possibly shared by multiple privileged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any output type that allows key material.
	# Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the user's need for lack of txid malleability. Further policy extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.

[instagibbs]

removed this section as it's speaking on script templates rather than the key dust concept

[reardencode]

Suggested change

	1. The ephemeral anchor transaction should be 0-fee itself
	2. The transaction should only have a single child
	3. The ephemeral anchor must be spent
	# The ephemeral anchor transaction should be 0-fee itself
	# The transaction should only have a single child
	# The ephemeral anchor must be spent

[instagibbs]

What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.

Indeed it's not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and "only one child", to incentivize the mining of the spend of the dust.

This may be too much implementation bleeding into the BIP, and instead the implementation section could note its own limitations which is changed as the implementation changes?

[petertodd]

What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.

Indeed it's not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and "only one child", to incentivize the mining of the spend of the dust.

This may be too much implementation bleeding into the BIP, and instead the implementation section could note its own limitations which is changed as the implementation changes?

Yes, I would say removing mentions of TRUC from the BIP would make sense. Due to the many limitations of TRUC it will certainly be replaced in the future, most likely with some kind of general repace-by-fee-rate mechanism (as I've noted on bitcoindev, replace-by-fee-rate is already solving real transaction pinning in the wild right now, even without miner support). So there's no need for the BIP to be dependent on it. I would also strongly suggest that the actual implementation fix this issue; I'll try to find time to review it later and see if there's an easy way to do that.

I believe the "only one child" limitation would affect certain types of connector outputs, as used in Ark. Zero-value outputs are useful to implement a connector output, and there will probably be situations where having more than one of them in a single transaction is useful. That said, the one-child limitation is a more fundamental question of how exactly packages are relayed, so it's probably more reasonable to punt on fixing this limitation for now.

[instagibbs]

I would also strongly suggest that the actual implementation fix this issue; I'll try to find time to review it later and see if there's an easy way to do that.

It's all doable(maybe in near future), I'll leave notes in the other PR.

I believe the "only one child" limitation would affect certain types of connector outputs, as used in Ark. Zero-value outputs are useful to implement a connector output, and there will probably be situations where having more than one of them in a single transaction is useful.

Good point, I think in my mind I was conflating requirements for connector outputs(which don't have to be sitting in utxo set) vs control outputs which do in constructions like hierarchical payment channels. I have some unclear thoughts on how to relax this restriction so punting for now.

[glozow]

What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.

Indeed it's not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and "only one child", to incentivize the mining of the spend of the dust.

TRUCness is just a way of making it feasible to enforce the rules. There's not a reliance on TRUC, but the point is to clearly describe a specific solution that works and why. BIP 431 itself generally describes topological restrictions on which you can build less pinning-prone policies, with 1 section more specifically about a 1-parent-1-child ruleset. One can imagine another ruleset in a different context but with the same design goals.

Similarly, you could structure this BIP as:

• Motivation: 0-value anchors would be nice
• Design Goals: loosen policy to allow ephemeral dust, but easily enforce that it's always spent.
• 1 possible concrete method: 1 child only + 0-fee + TRUC. Link implementation, list rationale.
• Mention that, in the future, you could come up with another way to allow dust + enforce its ephemeralness in a completely different way.

[instagibbs]

Thanks for the feedback. I attempted to move all "implementation details" into that section, while keeping the specification clear enough.

I also renamed this to "ephemeral dust", because really this is all about handling dust and not about a new output script type ala Pay To Anchor(P2A) bitcoin/bitcoin#30352

Think I also broke something by changing names of the file.

[petertodd]

Suggested change

	When received by a peer for inclusion to the mempool an ephemeral dust transaction MUST:
	* Be an otherwise valid transaction
	* Be only considered for mining with ephemeral dust spent
	* Have only one ephemeral dust output (output values which would normally cause rejection)
	or will be rejected by policy. All other policy checks are left in place.
	These constraints apply only to mempool policy. Blocks are not
	invalidated by breaking these policy-only rules as they have no bearing on consensus.
	As an exception to the dust rule, a transaction with dust outputs will be considered for acceptance to a node's mempool if:
	* It has arrived as part of a package of two or more transactions
	* Other transactions in that package spend every dust output
	* The transaction(s) spending the dust outputs have an effective fee-rate equal or greater than the fee-rate of the transaction creating the dust
	This specification is aspirational. Actual implementations may place further restrictions for implementation reasons.

Rational: I think it's more clear and less wordy if we explain the specification in terms of how ephemeral dust is a relaxation of the dust rule, allowing transactions to do something they otherwise could not have done.

[instagibbs]

Took the clarity suggestion on making it a more straight forward relaxation.

I also rewrote the section hoping to stay as close as possible to the ideal, which is "don't make a block template that would result in dust entering UTXO set"

[petertodd]

Suggested change

	If a dust output never ends up unspent in a mining template, then the marginal
	exposure of the network to dust is minimized. Most identified use-cases
	of ephemeral dust only require a single dust output, so multiple dust outputs
	are left for a possible future extension.
	If dust outputs never ends up unspent in a mining template, then the marginal
	exposure of the network to dust is minimized. Requiring the transactions spending the dust to have a higher fee-rate ensures that miners do in fact have an incentive to immediately spend the dust.

Deleting since the "aspirational" spec isn't limited to a single dust output, and explaining the fee-rate rule.

[instagibbs]

Removing the single-anchor mention.

As for the other parts, you could imagine a linear chain of dust being spent(each tx 0-fee), with the ultimate transaction bringing exogenous fees to pay for the chain, so I'm not sure being specific about feerates of children is helpful for aspirational section.

In cluster mempool terms, the implementation could allow dust as long as it's all created and spent intra-chunk(or would be trimmed), since the miner template would never select a block that would result in the dust entering the UTXO set. It may not be worth the complexity, but seems possible at least, and much more general than current implementation.

[petertodd]

Suggested change

	== Security Considerations ==
	While CPFP anchors are expected to be a main use-case for ephemeral dust, their use can pose a mining centralization risk. Since it is more space-efficient to pay a miner out-of-band to get a transaction mined than to actually use a CPFP anchor output, large miners could potentially profit from offering out-of-band fee payment services that smaller miners can't offer. In cases where this space efficiency difference is significant, such as using CPFP anchors to pay fees on small transactions, this could act to steer fee revenue to more centralized miners, a threat to Bitcoin's overall decentralization security. Out-of-band fee payment will also result in dust being added to the UTXO set.
	Protocols and application developers SHOULD only use anchor outputs for fee payment as a last resort, if alternatives such as RBF with pre-signed transactions at different fee-rates are truly impractical.

IMO we need this section to give devs a nudge. We should put similar language in any keyless anchor BIP too.

[instagibbs]

I added a fee-efficiency section since I do think it's worth noting the relative ineffciency of multi-tx exogenous fee patterns(like anchors) compared to the other configurations possible with or without softforks.

[murchandamus]

Think I also broke something by changing names of the file.

It looks like you are missing the README table entry for this PR to pass the build checks

[murchandamus]

Looking over this draft again after the recent reframing from Ephemeral Anchors to Ephemeral Dust, I am no longer confident that the idea needs to be a BIP: it seems to me that the entire spec could be comprehensively described in a few sentences and it would likely suffice to publish it directly in the context of the implementation or project specific documentation.

[instagibbs]

@murchandamus Appreciate the feedback. I'll see if there are other places this kind of document can live when it comes to motivating a particular implementation.