bitcoin
Ephemeral Dust
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.
Node policy is not a standardizable subject matter in itself, and I'm not really seeing anything here to standardize?
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.
BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.
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.
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.
The idea of only using BIPs for standards that need to be adopted by "everybody" or are consensus rules has no precedent and makes no sense. There are lots of wallet standards, p2p messages, and services dedicated to SPV clients that are used by a small fraction of Bitcoin users and software. A large number of BIPs are not relevant to node software, but they are Bitcoin-specific and should have canonical implementation-agnostic specifications and documentation for multiple people to refer to.
@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.
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
@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
re-did the text to reflect the updated changes to the new PR https://github.com/bitcoin/bitcoin/pull/30239 with updated(shorter!) motivation section
Again, policy isn't a subject of standardization. While things like BIP 125 and TRUC got BIPs for signalling, there isn't anything like that here.
Again, I don't see that policy written anywhere, but don't want to overly bother people. I'll just make a BINANA or something if that's the general consensus.
I don’t think that it’s general consensus. While I agree with Luke that it would be troublesome if someone prescribed that all implementations must follow a specific mempool policy, I don’t see an issue with proposing a mempool policy that implementations can choose to adopt.
It's not a policy, it's the nature of it. There's nothing to coordinate between implementations.
Ephemeral Anchors seem potentially useful for LN implementations to coordinate on (see documentation in https://bitcoinops.org/en/topics/ephemeral-anchors/), in the context of BOLT3 for instance, or for other ecosystem projects (e.g. example use cases) to possibly adopt for inter-op. If yes, it seems valuable to add a draft here (it would need to see wider adoption to progress to final).
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.
updated taking or adapting all suggestions and added a small rationale section
Re-ack https://github.com/bitcoin/bips/commit/9e463fe466d2ff9f5d0b10ec7a2c526cd5ed2067 via Range-Diff
"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.
Let’s call this BIP 432
It's still not BIP material, thus not eligible for assignment or acceptance
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:
- Motivation: 0-value anchors would be nice
- Design Goals: loosen policy to allow ephemeral dust, but easily enforce that it's always spent.
- 1 possible concrete method: 1 child only + 0-fee + TRUC. Link implementation, list rationale.
- Mention that, in the future, you could come up with another way to allow dust + enforce its ephemeralness in a completely different way.