rename to ephemeral dust, move implementation sections around

Author: instagibbs

README.mediawiki

@@ -1225,6 +1225,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Gloria Zhao
 | Informational
 | Draft
+|-
+| [[bip-0432.mediawiki|432]]
+| Applications
+| Ephemeral Dust
+| Gregory Sanders
+| Informational
+| Draft
 |}
 
 <!-- IMPORTANT!  See the instructions at the top of this page, do NOT JUST add BIPs here! -->

bip-ephemeralanchors.mediawiki renamed to bip-0432.mediawiki

@@ -1,21 +1,20 @@
 <pre>
-  BIP: ?
+  BIP: 432
   Layer: Application
-  Title: Ephemeral Anchors
+  Title: Ephemeral Dust
   Author: Gregory Sanders <gsanders87@gmail.com>
-  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-432
   Status: Draft
   Type: Informational
   Created: 2023-01-11
   License: CC0 1.0 Universal
-  Requires: 431
 </pre>
 
 ==Introduction==
 
 ===Abstract===
 
-Ephemeral Anchors are a mempool policy carve-out that allows dust UTXOs,
+Ephemeral dust is a mempool policy carve-out that allows dust UTXOs,
 even 0-value, to be created, provided they are also spent in the mempool.
 
 ===Motivation===
@@ -42,83 +41,92 @@ spending the anchor is responsible for providing the funds.
 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.
 
-===Typical Configurations===
-
-For anchors using TRUC transactions, it's expected that they would take two output script forms:
-
-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`.
-
 ===Example Use Cases===
 
 * Batched payments with segregated fee pools: Batched payments that can be fee bumped without access to customer deposit-related key material
 * Simplified watchtowers/accelerators: No requirement to equip watchtowers with privileged key material, and no value to steal by those watchtowers
 * Multiparty smart contracts: LN BOLTs can be revamped to remove value-sapping anchors.
 * LN-Symmetry: During the contest period, no anchor value can be sourced endogenously.
 * [https://bitcoin.stackexchange.com/questions/100537/what-is-spacechain Spacechains]
-* Ark transactions
-* Timeout Trees
+* Ark transactions, for anchors and connector outputs
+* Timeout Trees, for anchors and connector outputs
 
 ===Related Work===
 
 [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.
 
 [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html Transaction Sponsors] is a softfork proposal to allow transactions to
 sponsor transactions with no explicit relationship in the classical UTXO
-model. Ephemeral Anchors can be viewed as a type of opt-in transaction sponsors implemented
+model. Ephemeral Dust with an un-keyed anchor can be viewed as a type of opt-in transaction sponsors implemented
 purely in policy.
 
-Using a 0-value CPFP anchor is not a new idea, see:
+Using a 0-value CPFP anchors is not a new idea, see:
 
 * [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015931.html LN-dev discussion on 0-value anchors]
 
 The discussion lacked a solution to the issue of the dust entering into the UTXO set
 causing negative externalities.
 
+===Fee Efficiency===
+
+As the common use-case of ephemeral dust will likely be anchors, it bears noting that anchors
+has vbyte overhead when directly compared to the endogenous fee cases(e.g., single transaction
+RBF), where no additional child transaction is required.
+When practical, endogenous fees should be strongly considered.
+
+SIGHASH_GROUP style proposals would also be a moderate improvement on fee efficiencies of
+exogenous fees such as anchors, but requires a softfork.
+
 ==Definitions==
 
-Ephemeral anchor: An output with dust value which is immediately spent by a child transaction.
+Ephemeral dust: An output with dust value which is immediately spent by a child transaction.
 
-Ephemeral anchor transaction: A transaction that has an ephemeral anchor
+Ephemeral dust transaction: A transaction that has an ephemeral dust output.
 
 ==Specification==
 
-When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
+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
+* The resulting mempool would not cause dust to be left in the UTXO set if a block template is generated by the node.
+
+Implementations, detailed further below, may place further restrictions for implementation reasons.
+
+These constraints apply only to mempool policy. Blocks are not
+invalidated by breaking these policy-only rules as they have no bearing on consensus.
+
+==Reference Implementation==
+
+The [https://github.com/bitcoin/bitcoin/pull/30239 Bitcoin Core implementation] enforces these specific rules:
 
 * Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction adhering to the corresponding topological constraints
 * Be 0-fee
 * Have only one dust value output (output values which would normally cause rejection)
-* Have its ephemeral anchor spent in the same TRUC cluster
+* Have its ephemeral dust spent in the same TRUC cluster
 
-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.
+or will be rejected by policy.
 
-==Rationale==
+TRUC transactions are allowed to be 0-fee, and the topological restrictions ensure
+that the parent transaction never ends up in a mining template without the ephemeral
+dust being spent.
+
+Future implementations may relax some of these constraints.
 
-To incentivize the mining of the spends of ephemeral anchors we require three things to be true:
+==Rationale==
 
-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
+This policy is a relaxation to dust policies that most node software enforces.
 
-With these restrictions in place, the only endogenous incentives to mine the ephemeral
-anchor transaction is to mine the transaction along with the child transaction
-spending the anchor. TRUC transaction restrictions inherently follow the single
-child rule, though it's not strictly necessary. Further standards can relax
-the TRUC transaction requirement in favor of just the necessary requirements.
+If a dust output never ends up unspent in a mining template, then the marginal
+exposure of the network to dust is minimized. There are various ways to achieve
+this goal, which means precise rules are left to implementations.
+The implementation section details how these restrictions are enforced and under
+what circumstances for the known implementations to aid in interoperability.
 
 == Backward compatibility ==
 
-Ephemeral anchor spends were previously non-standard, so there are no known conflicts
+Ephemeral dust creation was previously non-standard, so there are no known conflicts
 with previous usage.
 
-==Implementation==
-
-https://github.com/bitcoin/bitcoin/pull/30239
-
 ==Acknowledgements==
 
 Thank you to all those listed for foundational work