Add ephemeral dust BIP

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-0432.mediawiki

@@ -0,0 +1,146 @@
+<pre>
+  BIP: 432
+  Layer: Applications
+  Title: Ephemeral Dust
+  Author: Gregory Sanders <[email protected]>
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0432
+  Status: Draft
+  Type: Informational
+  Created: 2023-01-11
+  License: CC0-1.0
+</pre>
+
+==Introduction==
+
+===Abstract===
+
+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===
+
+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.
+
+With [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transactions
+and basic package relay, users can generate and propagate 0-fee transactions provided
+a descendant transaction includes the proper fee for the package. In many cases
+these fees can be directly sourced from a freely spendable output, with the resulting
+change output being decremented by the required fee amount.
+
+In some cases however there are no freely spendable outputs to source this fee value
+from, and in these cases an "anchor" is employed.
+
+[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.
+
+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.
+
+===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, 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 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 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 dust: An output with dust value which is immediately spent by a child transaction.
+
+Ephemeral dust transaction: A transaction that has an ephemeral dust output.
+
+==Specification==
+
+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 dust spent in the same TRUC cluster
+
+or will be rejected by policy.
+
+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.
+
+==Rationale==
+
+This policy is a relaxation to dust policies that most node software enforces.
+
+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 dust creation was previously non-standard, so there are no known conflicts
+with previous usage.
+
+==Acknowledgements==
+
+Thank you to all those listed for foundational work
+and insightful feedback (ordered by last name):
+
+* Richard Myers
+* James O'Beirne
+* Antoine Poinsot
+* Antoine Riard 
+* Jeremy Rubin
+* Bastien Teinturier
+* Anthony Towns
+* Gloria Zhao
+
+==Copyright==
+
+This document is licensed under the Creative Commons CC0 1.0 Universal license.