Opening to allow discussion on the text separately from the Bitcoin Core implementation here https://github.com/bitcoin/bitcoin/pull/30239
Example usage: https://github.com/instagibbs/bolts/commits/zero_fee_commitment https://github.com/instagibbs/lightning/commits/commit_zero_fees
@ariard bring comment from https://github.com/instagibbs/bolts/commit/4830650f0d45e7ff2c8637e05dc89d14d0d9a506#diff-6bed824879b760d329ec379b16a1d0e78ffba034fdfa13b95cf0480e09fa7c4bR156
This is uncertain to me how this rule works with trimmed HTLCs on LN commitment transactions making their fees non-zero, even assuming anchor outputs where second-stage txn are signed with 0-feerate.
I gave an example spec at the top, and implementation(of most of it) for CLN. Links again here:
Example usage: https://github.com/instagibbs/bolts/commits/zero_fee_commitment https://github.com/instagibbs/lightning/commits/commit_zero_fees
TLDR: trimmed value can go into the anchor itself, and is simply spent to fees by the spender.
Otherwise a time-sensitive package can be tampered by third-parties entering into replacement cycling games, without being a direct off-chain counterparty to the target transaction traffic.
In the BIP I can mention that it allows any party to spend, therefore any party can attempt a cycling attack. We’re not going to agree on the severity of the attack, so it’s up to implementer to do their own research.
TLDR: trimmed value can go into the anchor itself, and is simply spent to fees by the spender.
I believe this is broken - Let’s say you have Alice and Bob sharing a Lightning channel, with max_accepted_htlcs (483) on both sides. Alice is a routing hop allowing HTLC forward going through Alice-Bob link. Bob circularly routes 483 offered HTLCs of value 330 satoshis (total amount 159390 satoshis). Those HTLCs are symmetrically committed on both Alice and Bob states. Assuming Bob can broadcast privately to a transaction accelerator with a child pocketing the anchor itself, Bob can mine the commitment transaction and steals 159390 satoshis from Alice’s balance.
Thanks to correct me if my understanding of option_commit_zero_fee is incorrect.
As of today, Bob could do the same attack by routing the HTLCs, however as the trimmed HTLCs are committed as miner fees, if Bob does not have low-hashrate capabilities, he cannot steal from Alice. Moving trimmed HTLC amounts from miners fees to a anyone-can-spend amount changes notably the threat model, in my opinion.
In the BIP I can mention that it allows any party to spend, therefore any party can attempt a cycling attack. We’re not going > to agree on the severity of the attack, so it’s up to implementer to do their own research.
While I agree that we won’t agree on the severity of a replacement cycling attack, I disagree on the deference to put on implementers the responsibility to do their own research on the security of such proposal. Not only this is unfavorable practice for Internet protocol standardization works (all IETF RFCs must have mandatory security sections - RFC 3552), beyond for the given proposal it modifies the attacker incentives model as anyone on the peer-to-peer transaction-relay network can enter into replacement cycling attacks against your time-sensitive packages or massive transaction batch.
Allowing anyone to tamper with packages is not only an issue for the safety of your use-case funds, it does open the door to adversaries tamper with the global transaction traffic, with potential way to realize gains. In the past, miners-harvesting attacks have been considered, and here it’s opening one. If you know that the transaction issuer of this transaction pattern will automatically fee-bump its package after X blocks without confirmation, anyone-can-spend ephemeral anchor allows you to substitute a “honest” CPFP at 20 sat/vbytes with a “malicious" CPFP at 30 sat/vbytes and then evicts this CPFP to trigger an eviction of the 0-fee parent itself from network mempools.
For this last reason, I think that anyone-can-spend ephemeral anchor should be reconsidered and locking the ephemeral anchor under a counterparty pubkey should be introduced, as we’re doing with anchor outputs on lightning commitment transactions today. I understand the efficiency reasons to use an OP_TRUE though I’m unsure it’s worth the newly introduced safety weaknesses.
As of today, Bob could do the same attack by routing the HTLCs, however as the trimmed HTLCs are committed as miner fees, if Bob does not have low-hashrate capabilities, he cannot steal from Alice. Moving trimmed HTLC amounts from miners fees to a anyone-can-spend amount changes notably the threat model, in my opinion. @ariard it’s an implementation detail for both Bitcoin Core and LN spec, but your hesitancy has caused me to look for a better solution than I was previously thinking: https://delvingbitcoin.org/t/ephemeral-anchors-and-mev/383
While I agree that we won’t agree on the severity of a replacement cycling attack
I’m fine adding some warning text wherever to inform implementors. Propose some please.
For this last reason, I think that anyone-can-spend ephemeral anchor should be reconsidered and locking the ephemeral anchor under a counterparty pubkey should be introduced, as we’re doing with anchor outputs on lightning commitment transactions today. I understand the efficiency reasons to use an OP_TRUE though I’m unsure it’s worth the newly introduced safety weaknesses.
I think the story for keyless is much simpler, even if you personally disagree with the relative security of it.
Anything that’s relay-standard now would be a potential “rug” if it suddenly required you to be V3, that you must RBF all sibling spends, etc. If we instituted a rule anyways safely somehow, it may interfere with future relaxations where we don’t care about dust(say, widespread utreexo deployment). Regardless today it also has a weaker anti-dust story as it can’t be cleaned up except by key owners.
We’re just not going to agree on this given our nearly year long discussions of cycle replacement attacks and similar, and it’ll be up to others to weigh in on this point for specific use-cases. I apologize for not moving forward with this line of discussion from here on out.
Node policy is not a standardizable subject matter in itself, and I’m not really seeing anything here to standardize?
I’ll let others weigh in, but in general I’d like to have a common place to have a tx format, like this, publicly documented, with some suggestions for implementors, even if we cannot force anyone to do so.
Related, I see no mention of banning policy in BIP rules; let me know if I missed something.
I’ll leave this PR open for now.
I’ll let others weigh in
For what it’s worth i think ti’s useful to have a BIP for this.
BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.
By this same token why bother writing BIPs for output script descriptors? For deterministic key generation? It’s most of the time an individual decision whether to use a feature. But that doesn’t change the fact that it’s useful to have a public, implementation-agnostic, documentation for anything where inter-compatibility is needed.
107+
108+Ephemeral anchor transaction: A transaction that has an ephemeral anchor
109+
110+==Specification==
111+
112+A new output script type is made policy standard to spend, known as an ephemeral anchor.
109+
110+==Specification==
111+
112+A new output script type is made policy standard to spend, known as an ephemeral anchor.
113+
114+Ephemeral anchors of any satoshi value are standard for relay.
125+as this is a policy-only change.
126+
127+It is recommended that miners should not mine ephemeral anchor transactions
128+without also mining the spend in the same block. This means miners should not
129+prioritise transactions that create ephemeral anchors but instead should just prioritise the spend;
130+mining software is encouraged to enforce that limitation.
prioritisetransaction when it notices the tx being prioritised creates an EA output?
128+without also mining the spend in the same block. This means miners should not
129+prioritise transactions that create ephemeral anchors but instead should just prioritise the spend;
130+mining software is encouraged to enforce that limitation.
131+
132+No witness data for ephemeral anchors spends should be allowed, to preclude witness
133+stuffing.
Mixes MUST and should; these are all relay policies, so shouldn’t they all be at the same level of compulsion?
Arguably it may be attractive for miners to stuff witness data in here – if they want to include modest amounts of arbitrary data in a block, then doing it in the witness is cheaper than anywhere else, and if someone else is paying for the tx that’s associated with the witness, that’s cheaper than them creating a dummy tx themselves.
BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.
I suspect if this is a non-negotiable for this repo and this BIP editor (and hence won’t get a BIP number) then we’ll need a bips-policy repo or something (under the same GitHub organization perhaps). I get Luke’s perspective to some extent (default policy proposals are certainly a very different animal to say consensus rule proposals) but this shouldn’t be stunting collaboration between Core developers and Lightning developers on policy proposals. Personally I’d rather these draft proposals were incorporated into the BIP process but if that isn’t going to happen then the documents need to be worked on in a different repo and with a different numbering system. Of course there is no guarantee these policy proposals will ever be merged into Core or an alternative implementation (they’d need to go through the Core etc review process to be merged) but that doesn’t mean people can’t draft and collaborate on proposals. Applies to #1541 too.
@glozow: I personally agree with you. I asked Luke about this on X/Twitter (it is public so I hope he doesn’t mind me copying it over here) and he responded:
“Transaction pinning” AFAIK is a result of policy centralization efforts, not a real problem. The alternative is to encourage diverse policies, and at the technical level, to prepare multiple alternative transaction variants to ensure one being rejected won’t be a problem.
So his perspective is not that BIPs need to be adopted by everybody or have to be consensus rules (as you state) but that he thinks attempts to standardize policy aren’t a good idea and are perhaps even harmful. Again I personally disagree with that perspective (and I suspect everyone working on these proposals also disagree with that perspective) but just clarifying what Luke’s perspective is.
I suspect if this is a non-negotiable for this repo and this BIP editor (and hence won’t get a BIP number) then we’ll need a bips-policy repo or something (under the same GitHub organization perhaps).
In the absence of convincing Luke otherwise or adding a new BIP editor who disagrees directly with Luke on this topic it seems to me like a new repo for policy related BIPs is the best way forward.
0@@ -0,0 +1,160 @@
1+<pre>
2+ BIP: ?
3+ Layer: Mempool Policy
4+ Title: Ephemeral Anchors
5+ Author: Gregory Sanders <gsanders87@gmail.com>
6+ Status: Draft
7+ License: BSD-3-Clause
8+ Type: Standards Track
0 Type: Informational
Perhaps “Informational” rather than “Standards Track”, as policy is an individual, per-node decision, but it may be helpful to document policy R&D as informational BIPs.
0@@ -0,0 +1,160 @@
1+<pre>
2+ BIP: ?
3+ Layer: Mempool Policy
Mempool Policy layer.
144+==Acknowledgements==
145+
146+Thank you to all those listed for foundational work
147+and insightful feedback(in last name order):
148+
149+* Richard Meyers
(if this refers to https://twitter.com/remyers_)
0* Richard Myers
pushed fixups, but marking as draft until I come back to this. Scope has changed substantially so this essentially needs a complete re-write.
short motivation for changes for those interested here: https://github.com/bitcoin/bitcoin/pull/29001#issuecomment-2025830996
25+of a getting a transaction mined that would otherwise be rational for the miner
26+to include in the next block without the attacker paying anything in many cases.
27+This can result in wallets simply not supporting fee bumping due to complexity,
28+or in certain smart contract cases such as Hash Time Locked Contracts, outright theft.
29+
30+[https://github.com/bitcoin/bitcoin/pull/28948 V3] transactions, which this proposal is built on, greatly mitigates [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP125]
@glozow yes thanks for reminding me, a number of things have changed like the output format requirements, sibling eviction being broken out into its own TRUC feature, etc.
I’ll revive this this week
0@@ -0,0 +1,123 @@
1+<pre>
2+ BIP: ?
3+ Layer: Application
4+ Title: Ephemeral Anchors
5+ Author: Gregory Sanders <gsanders87@gmail.com>
0 Author: Gregory Sanders <gsanders87@gmail.com>
1 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
0@@ -0,0 +1,123 @@
1+<pre>
2+ BIP: ?
3+ Layer: Application
4+ Title: Ephemeral Anchors
5+ Author: Gregory Sanders <gsanders87@gmail.com>
6+ Status: Draft
7+ License: BSD-3-Clause
8+ Type: Informational
9+ Created: 2023-01-11
Order must be “Type, Created, License”
0 Type: Informational
1 Created: 2023-01-11
2 License: BSD-3-Clause
24+bloating the UTXO set and increasing the validation burden for validating
25+nodes.
26+
27+With [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transactions
28+and basic package relay, users can generate and propogate 0-fee transactions provided
29+a descendant spend includes the proper fee for the package. In many cases
0a descendant transaction includes the proper fee for the package. In many cases
34+from, and in these cases an "anchor" is employed.
35+
36+[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
37+allows a small amount of contract value to be given to an output to merely allow network relay
38+by avoiding dust checks, but not as the primary source of fee funds. Instead the child
39+spend of the anchor is given the responsibility of bringing funds.
Maybe:
0by avoiding dust checks, but not as the primary source of fee funds. Instead the child transaction
1spending the anchor is given the responsibility of bringing funds.
36+[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
37+allows a small amount of contract value to be given to an output to merely allow network relay
38+by avoiding dust checks, but not as the primary source of fee funds. Instead the child
39+spend of the anchor is given the responsibility of bringing funds.
40+
41+It is be cleaner for this abstraction and others if instead of requiring
Maybe
0It is cleaner for this abstraction and others if instead of requiring
or
0It would be cleaner for this abstraction and others if instead of requiring
41+It is be cleaner for this abstraction and others if instead of requiring
42+dust values in anchors, the anchor itself can be 0 value.
43+
44+===Typical Configurations===
45+
46+For anchors using TRUC transactions, it's expected that they would take two scriptPubKey forms:
0For anchors using TRUC transactions, it's expected that they would take two output script forms:
43+
44+===Typical Configurations===
45+
46+For anchors using TRUC transactions, it's expected that they would take two scriptPubKey forms:
47+
48+1. Keyed anchor: A key, shared by possibly multiple privelaged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
Opinionated suggestion, feel free to ignore:
01. Keyed anchor: A key, shared by possibly multiple privileged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
46+For anchors using TRUC transactions, it's expected that they would take two scriptPubKey forms:
47+
48+1. Keyed anchor: A key, shared by possibly multiple privelaged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
49+output type that allows key material.
50+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
51+extensions could allow output templates such as the scriptPubKey <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
Opinionated suggestion, feel free to ignore:
0extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
60+* Ark transactions
61+* Timeout Trees
62+
63+===Related Work===
64+
65+[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 drawbacks of these are the necessity of a softfork and all that entails.
It feels like “all that entails” is missing something. Should that be “all that that entails”, or “all that a softfork entails”?
0[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 proposals are the necessity of a softfork and all that that entails.
76+The discussion lacked a solution to the issue of the dust entering into the utxo set
77+causing negative externalities.
78+
79+==Definitions==
80+
81+Ephemeral anchor: An output with dust values which are spent by a child transaction.
There is only one, right?
0Ephemeral anchor: An output with dust value which is immediately spent by a child transaction.
82+
83+Ephemeral anchor transaction: A transaction that has an ephemeral anchor
84+
85+==Specification==
86+
87+When received by a peer for inclusion to the mempool an ephemeral anchors transaction MUST:
0When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
0@@ -0,0 +1,123 @@
1+<pre>
2+ BIP: ?
3+ Layer: Application
4+ Title: Ephemeral Anchors
5+ Author: Gregory Sanders <gsanders87@gmail.com>
6+ Status: Draft
7+ License: BSD-3-Clause
116+* Jeremy Rubin
117+* Bastien Teinturier
118+* Anthony Towns
119+* Gloria Zhao
120+
121+==References and Rationale==
117+* Jeremy Rubin
118+* Bastien Teinturier
119+* Anthony Towns
120+* Gloria Zhao
121+
122+=Copyright==
0==Copyright==
It’s not a policy, it’s the nature of it. There’s nothing to coordinate between implementations.
The point is that multiple LN implementations would like to use a specific output construction under specific circumstances. Currently, most nodes would not relay transactions with such outputs. Node operators might be sympathetic to the specific use-case, but will not want to be more permissive than necessary, while on the other hand, the carve-out needs to enable the use-case to make sense. It would neither make sense if there were multiple different variants for the output constructions nor to more broadly accept output constructions than necessary.
Therefore, this proposal only makes sense when there is coordination on what nodes would relay on the network and the precise parameters for the output construction that fits the use-case. The design of this output construction is subject of this draft.
12+
13+==Introduction==
14+
15+===Abstract===
16+
17+Ephemeral Anchors are a mempool policy carve-out that allows any value utxos,
0Ephemeral Anchors are a mempool policy carve-out that allows UTXOs of any value,
13+==Introduction==
14+
15+===Abstract===
16+
17+Ephemeral Anchors are a mempool policy carve-out that allows any value utxos,
18+even 0-value dust, to be created, provided it is also spent within the same
Previously plural:
0even 0-value dust, to be created, provided they are also spent within the same
21+===Motivation===
22+
23+Relay dust limits have been in place in most implementations of the Bitcoin
24+protocol to discourage the creation of UTXOs that are never spent in the future,
25+bloating the UTXO set and increasing the validation burden for validating
26+nodes.
Switching tenses:
0Relay dust limits have been in place in most implementations of the Bitcoin
1protocol to discourage the creation of UTXOs that are never spent in the future,
2bloat the UTXO set, and increase the validation burden for validating
3nodes.
35+from, and in these cases an "anchor" is employed.
36+
37+[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
38+allows a small amount of contract value to be given to an output to merely allow network relay
39+by avoiding dust checks, but not as the primary source of fee funds. Instead the child transaction
40+spending the anchor is given the responsibility of bringing funds.
What do you think about:
0[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
1allows a small amount of contract value to be given to an output to allow network relay
2by passing dust checks, but not as the primary source of fee funds. Instead, the child transaction
3spending the anchor is responsible for providing the funds.
38+allows a small amount of contract value to be given to an output to merely allow network relay
39+by avoiding dust checks, but not as the primary source of fee funds. Instead the child transaction
40+spending the anchor is given the responsibility of bringing funds.
41+
42+It is cleaner for this abstraction and others if instead of requiring
43+dust values in anchors, the anchor itself can be 0 value.
“requiring dust values” ⇒ Isn’t the issue that they must have above dust amounts?
How about:
0In this and similar abstractions it would be cleaner if the anchor itself could be 0-value
1instead of requiring anchors to exceed dust amounts.
44+
45+===Typical Configurations===
46+
47+For anchors using TRUC transactions, it's expected that they would take two output script forms:
48+
49+1. Keyed anchor: A key, shared by possibly multiple privileged parties, is used to encumber the anchor. This could also be `tr()`, `p2wsh()` or any
How about “shared by possibly multiple” → “possibly shared by multiple”?
01. Keyed anchor: A key, possibly shared by multiple privileged parties, is used to encumber the anchor. This could be `tr()`, `p2wsh()` or any
52+extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
53+
54+===Example Use Cases===
55+
56+* Batched payments with segregated fee pools: Batched payments that can be fee bumped without access to customer deposit-related key material
57+* Simplified watchtowers/accelerators: No requirement for watchtowers to be registered with privileged key material, and no value to steal by those watchtowers
How about:
0* Simplified watchtowers/accelerators: No requirement to equip watchtowers with privileged key material, and no value to steal by those watchtowers
64+===Related Work===
65+
66+[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 drawbacks of these are the necessity of a softfork.
67+
68+[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html Transaction Sponsors] is a softfork proposal to allow transactions to
69+indirectly sponsor transactions with no explicit relationship in the classical utxo
Wouldn’t it be a direct relationship?
0sponsor transactions with no explicit relationship in the classical UTXO
77+The discussion lacked a solution to the issue of the dust entering into the utxo set
78+causing negative externalities.
79+
80+==Definitions==
81+
82+Ephemeral anchor: An output with dust value which is immediately spent by a child transaction.
85+
86+==Specification==
87+
88+When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
89+
90+* Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction which enforces topology constraints
TRUC transactions do not enforce topology constraints. TRUC transactions request nodes to enforce topological constraints. How about:
0* Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction adhering to the corresponding topological constraints
87+
88+When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
89+
90+* Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction which enforces topology constraints
91+* Be 0-fee
92+* Have only one dust value output
This could be understood to e.g. forbid a nulldata output without an amount. Did you mean:
0* Have exactly one ephemeral anchor and may not create additional dust value UTXOs
88+When received by a peer for inclusion to the mempool an ephemeral anchor transaction MUST:
89+
90+* Be an otherwise valid [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transaction which enforces topology constraints
91+* Be 0-fee
92+* Have only one dust value output
93+* Have the dust value spent in the same TRUC cluster
0* Have its emphemeral anchor spent in the same TRUC cluster
92+* Have only one dust value output
93+* Have the dust value spent in the same TRUC cluster
94+
95+or will be rejected by policy. All other policy checks are left in place.
96+If included in an otherwise valid block, these additional constraints do not apply
97+as this is a policy-only change.
Perhaps:
0These constraints apply only to mempool policy. Otherwise valid blocks are not
1invalidated by breaking these policy-only rules as they have no bearing on consensus.
106+https://github.com/bitcoin/bitcoin/pull/30239
107+
108+==Acknowledgements==
109+
110+Thank you to all those listed for foundational work
111+and insightful feedback(in last name order):
0and insightful feedback (in last name order):
Or maybe:
0and insightful feedback (ordered by last name):
61+* Ark transactions
62+* Timeout Trees
63+
64+===Related Work===
65+
66+[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 drawbacks of these are the necessity of a softfork.
Since it is one drawback shared by all of these proposals, ISTM that it should just be “drawback” instead of “drawbacks”.
0[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.
119+* Anthony Towns
120+* Gloria Zhao
121+
122+==Copyright==
123+
124+This document is licensed as Creative Commons CC0 1.0 Universal.
0This document is licensed under the Creative Commons CC0 1.0 Universal license.
5+ Author: Gregory Sanders <gsanders87@gmail.com>
6+ Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
7+ Status: Draft
8+ Type: Informational
9+ Created: 2023-01-11
10+ License: CC0 1.0 Universal
Oh, and since you build on TRUC Transactions, you should have:
0 License: CC0 1.0 Universal
1 Requires: 431
35+from, and in these cases an "anchor" is employed.
36+
37+[https://github.com/lightning/bolts/blob/master/03-transactions.md#to_local_anchor-and-to_remote_anchor-output-option_anchors LN]
38+allows a small amount of contract value to be given to an output to allow network relay
39+by passing dust checks, but not as the primary source of fee funds. Instead the child transaction
40+spending the anchor is responsibile for providing the funds.
0spending the anchor is responsible for providing the funds.
98+
99+==Rationale==
100+
101+To incentivize the mining of the spends of ephemeral anchors we require three things to be true:
102+
103+1. The ephemeral anchor transaciton should be 0-fee itself
01. The ephemeral anchor transaction should be 0-fee itself
104+2. The transaction should only have a single child
105+3. The ephemeral anchor must be spent
106+
107+With these restrictions in place, the only endogenous incentives to mine the ephemeral
108+anchor transaction is to mine the transaction along with the child transaction
109+spending the acnhor. TRUC transaction restrictions inherently follow the single
0spending the anchor. TRUC transaction restrictions inherently follow the single
24+protocol to discourage the creation of UTXOs that are never spent in the future,
25+bloat the UTXO set, and increase the validation burden for validating
26+nodes.
27+
28+With [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC] transactions
29+and basic package relay, users can generate and propogate 0-fee transactions provided
0and basic package relay, users can generate and propagate 0-fee transactions provided
46+
47+For anchors using TRUC transactions, it's expected that they would take two output script forms:
48+
49+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
50+output type that allows key material.
51+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
01. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the user's need for lack of txid malleability. Further policy
72+
73+Using a 0-value CPFP anchor is not a new idea, see:
74+
75+* [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015931.html LN-dev discussion on 0-value anchors]
76+
77+The discussion lacked a solution to the issue of the dust entering into the utxo set
0The discussion lacked a solution to the issue of the dust entering into the UTXO set
Changes look good to me, found a few typos
ACK 8852274d86a7f8b203a5fcae85726769671dffd9
115+Ephemeral anchor spends were previously non-standard, so there are no known conflicts
116+with previous usage.
117+
118+==Implementation==
119+
120+https://github.com/bitcoin/bitcoin/pull/30239
Question (as I may be confused): Per this current implementation PR, “it makes sense to retarget this feature more narrowly by not introducing a new output type for now, and simple focusing on the feature of allowing temporary dust in the mempool.” Is it the full expected implementation, or a partial one, with the tentative plan to add a new output type down the road?
(Edit: If a partial implementation, perhaps mention that aspect.)
That’s the full implementation.
https://github.com/bitcoin/bitcoin/pull/30352 is a now separate PR and concept that introduces a new output type for the specific use-case of key-less anchors
“Be an otherwise valid TRUC transaction adhering to the corresponding topological constraints”
What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.
47+For anchors using TRUC transactions, it's expected that they would take two output script forms:
48+
49+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
50+output type that allows key material.
51+1. Un-keyed anchor: `P2SH(OP_TRUE)` or `P2WSH(OP_TRUE)`, depending on the user's need for lack of txid malleability. Further policy
52+extensions could allow output templates such as the output script <code>OP_1 <0x4e73></code> or a bare `OP_TRUE`.
0# 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`.
100+
101+To incentivize the mining of the spends of ephemeral anchors we require three things to be true:
102+
103+1. The ephemeral anchor transaction should be 0-fee itself
104+2. The transaction should only have a single child
105+3. The ephemeral anchor must be spent
0# The ephemeral anchor transaction should be 0-fee itself
1# The transaction should only have a single child
2# The ephemeral anchor must be spent
Let’s call this BIP 432
It’s still not BIP material, thus not eligible for assignment or acceptance
Good start for TRUC-ephemeral anchor, looking forward to OP_TRUE and/or OP_1 0x4e73 anchors.
I learned from this transaction that paying to short segwit v1 addresses is already standard, so it’s a smaller change than I had realized to standardize short witness ephemeral anchors.
What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.
Indeed it’s not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and “only one child”, to incentivize the mining of the spend of the dust.
This may be too much implementation bleeding into the BIP, and instead the implementation section could note its own limitations which is changed as the implementation changes?
What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.
Indeed it’s not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and “only one child”, to incentivize the mining of the spend of the dust.
This may be too much implementation bleeding into the BIP, and instead the implementation section could note its own limitations which is changed as the implementation changes?
Yes, I would say removing mentions of TRUC from the BIP would make sense. Due to the many limitations of TRUC it will certainly be replaced in the future, most likely with some kind of general repace-by-fee-rate mechanism (as I’ve noted on bitcoindev, replace-by-fee-rate is already solving real transaction pinning in the wild right now, even without miner support). So there’s no need for the BIP to be dependent on it. I would also strongly suggest that the actual implementation fix this issue; I’ll try to find time to review it later and see if there’s an easy way to do that.
I believe the “only one child” limitation would affect certain types of connector outputs, as used in Ark. Zero-value outputs are useful to implement a connector output, and there will probably be situations where having more than one of them in a single transaction is useful. That said, the one-child limitation is a more fundamental question of how exactly packages are relayed, so it’s probably more reasonable to punt on fixing this limitation for now.
I would also strongly suggest that the actual implementation fix this issue; I’ll try to find time to review it later and see if there’s an easy way to do that.
It’s all doable(maybe in near future), I’ll leave notes in the other PR.
I believe the “only one child” limitation would affect certain types of connector outputs, as used in Ark. Zero-value outputs are useful to implement a connector output, and there will probably be situations where having more than one of them in a single transaction is useful.
Good point, I think in my mind I was conflating requirements for connector outputs(which don’t have to be sitting in utxo set) vs control outputs which do in constructions like hierarchical payment channels. I have some unclear thoughts on how to relax this restriction so punting for now.
What is the rational to limit ephemeral outputs to being spent by transactions adhering to the TRUC standard? The goal of ensuring that dust outputs are immediately spent in the same block has nothing to do with TRUC.
Indeed it’s not strictly required as noted in the rationale section. I leveraged the TRUC implementation in Core to have the 0-fee requirement of the parent(pre-cluster mempool non-TRUC tx are restricted to minrelay or higher), and “only one child”, to incentivize the mining of the spend of the dust.
TRUCness is just a way of making it feasible to enforce the rules. There’s not a reliance on TRUC, but the point is to clearly describe a specific solution that works and why. BIP 431 itself generally describes topological restrictions on which you can build less pinning-prone policies, with 1 section more specifically about a 1-parent-1-child ruleset. One can imagine another ruleset in a different context but with the same design goals.
Similarly, you could structure this BIP as:
Thanks for the feedback. I attempted to move all “implementation details” into that section, while keeping the specification clear enough.
I also renamed this to “ephemeral dust”, because really this is all about handling dust and not about a new output script type ala Pay To Anchor(P2A) https://github.com/bitcoin/bitcoin/pull/30352
Think I also broke something by changing names of the file.
81+* Be only considered for mining with ephemeral dust spent
82+* Have only one ephemeral dust output (output values which would normally cause rejection)
83+
84+or will be rejected by policy. All other policy checks are left in place.
85+These constraints apply only to mempool policy. Blocks are not
86+invalidated by breaking these policy-only rules as they have no bearing on consensus.
0
1As an exception to the dust rule, a transaction with dust outputs will be considered for acceptance to a node's mempool if:
2
3* It has arrived as part of a package of two or more transactions
4* Other transactions in that package spend every dust output
5* The transaction(s) spending the dust outputs have an effective fee-rate equal or greater than the fee-rate of the transaction creating the dust
6
7This specification is aspirational. Actual implementations may place further restrictions for implementation reasons.
Rational: I think it’s more clear and less wordy if we explain the specification in terms of how ephemeral dust is a relaxation of the dust rule, allowing transactions to do something they otherwise could not have done.
Took the clarity suggestion on making it a more straight forward relaxation.
I also rewrote the section hoping to stay as close as possible to the ideal, which is “don’t make a block template that would result in dust entering UTXO set”
90+This policy is a relaxation to dust policies that most node software enforces.
91+
92+If a dust output never ends up unspent in a mining template, then the marginal
93+exposure of the network to dust is minimized. Most identified use-cases
94+of ephemeral dust only require a single dust output, so multiple dust outputs
95+are left for a possible future extension.
0If dust outputs never ends up unspent in a mining template, then the marginal
1exposure of the network to dust is minimized. Requiring the transactions spending the dust to have a higher fee-rate ensures that miners do in fact have an incentive to immediately spend the dust.
Deleting since the “aspirational” spec isn’t limited to a single dust output, and explaining the fee-rate rule.
Removing the single-anchor mention.
As for the other parts, you could imagine a linear chain of dust being spent(each tx 0-fee), with the ultimate transaction bringing exogenous fees to pay for the chain, so I’m not sure being specific about feerates of children is helpful for aspirational section.
In cluster mempool terms, the implementation could allow dust as long as it’s all created and spent intra-chunk(or would be trimmed), since the miner template would never select a block that would result in the dust entering the UTXO set. It may not be worth the complexity, but seems possible at least, and much more general than current implementation.
100+
101+== Backward compatibility ==
102+
103+Ephemeral dust creation was previously non-standard, so there are no known conflicts
104+with previous usage.
105+
0
1== Security Considerations ==
2
3While CPFP anchors are expected to be a main use-case for ephemeral dust, their use can pose a mining centralization risk. Since it is more space-efficient to pay a miner out-of-band to get a transaction mined than to actually use a CPFP anchor output, large miners could potentially profit from offering out-of-band fee payment services that smaller miners can't offer. In cases where this space efficiency difference is significant, such as using CPFP anchors to pay fees on small transactions, this could act to steer fee revenue to more centralized miners, a threat to Bitcoin's overall decentralization security. Out-of-band fee payment will also result in dust being added to the UTXO set.
4
5Protocols and application developers SHOULD only use anchor outputs for fee payment as a last resort, if alternatives such as RBF with pre-signed transactions at different fee-rates are truly impractical.
IMO we need this section to give devs a nudge. We should put similar language in any keyless anchor BIP too.
Think I also broke something by changing names of the file.
It looks like you are missing the README table entry for this PR to pass the build checks
