Add ephemeral anchor BIP proposal

bip-ephemeralanchors.mediawiki

@@ -0,0 +1,138 @@
+<pre>
+  BIP: ?
+  Layer: Application
+  Title: Ephemeral Anchors
+  Author: Gregory Sanders <[email protected]>
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+  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,
+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 propogate 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 responsibile 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 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
+
+===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
+purely in policy.
+
+Using a 0-value CPFP anchor 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.
+
+==Definitions==
+
+Ephemeral anchor: An output with dust value which is immediately spent by a child transaction.
+
+Ephemeral anchor transaction: A transaction that has an ephemeral anchor
+
+==Specification==
+
+When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
+
+* 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
+
+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.
+
+==Rationale==
+
+To incentivize the mining of the spends of ephemeral anchors we require three things to be true:
+
+1. The ephemeral anchor transaciton should be 0-fee itself
+2. The transaction should only have a single child
+3. The ephemeral anchor must be spent
+
+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 acnhor. 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.
+
+== Backward compatibility ==
+
+Ephemeral anchor spends were 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
+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.