-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
rename to ephemeral dust, move implementation sections around
- Loading branch information
1 parent
9e463fe
commit 31041f6
Showing
1 changed file
with
39 additions
and
36 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,21 +1,20 @@ | ||
| <pre> | ||
| BIP: ? | ||
| BIP: 432 | ||
| Layer: Application | ||
| Title: Ephemeral Anchors | ||
| Title: Ephemeral Dust | ||
| Author: Gregory Sanders <[email protected]> | ||
| 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,35 +41,26 @@ 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] | ||
|
|
@@ -79,45 +69,58 @@ causing negative externalities. | |
|
|
||
| ==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: | ||
| When received by a peer for inclusion to the mempool an ephemeral dust 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 | ||
| * 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. | ||
|
|
||
| ==Rationale== | ||
|
|
||
| To incentivize the mining of the spends of ephemeral anchors we require three things to be true: | ||
| This policy is a relaxation to dust policies that most node software enforces. | ||
|
|
||
| 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 | ||
| 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. | ||
|
|
||
| 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. | ||
| 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 | ||
| 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 | ||
| without introducing more incentives to leave dust in the UTXO | ||
| set. | ||
|
|
||
| ==Acknowledgements== | ||
|
|
||
|
|
||