From fdaf837fc5ab84806df2175192c70d98264b9e62 Mon Sep 17 00:00:00 2001 From: Greg Sanders Date: Wed, 11 Jan 2023 12:02:01 -0500 Subject: [PATCH] Add ephemeral dust BIP --- README.mediawiki | 7 +++ bip-0432.mediawiki | 146 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 153 insertions(+) create mode 100644 bip-0432.mediawiki diff --git a/README.mediawiki b/README.mediawiki index 33f7a8f71e..39cc4c120f 100644 --- a/README.mediawiki +++ b/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 |} diff --git a/bip-0432.mediawiki b/bip-0432.mediawiki new file mode 100644 index 0000000000..a9b0933f3c --- /dev/null +++ b/bip-0432.mediawiki @@ -0,0 +1,146 @@ +
+  BIP: 432
+  Layer: Applications
+  Title: Ephemeral Dust
+  Author: Gregory Sanders 
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0432
+  Status: Draft
+  Type: Informational
+  Created: 2023-01-11
+  License: CC0-1.0
+
+ +==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.