Ephemeral anchors

[instagibbs]

Opening to allow discussion on the text separately from the Bitcoin Core implementation here bitcoin/bitcoin#29001

Example usage:
https://github.com/instagibbs/bolts/commits/zero_fee_commitment
https://github.com/instagibbs/lightning/commits/commit_zero_fees

[instagibbs]

@ariard bring comment from instagibbs/bolts@4830650#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.

[ariard]

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.

[luke-jr]

Node policy is not a standardizable subject matter in itself, and I'm not really seeing anything here to standardize?

[instagibbs]

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.

[instagibbs]

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.

[luke-jr]

BIPs are for standardization across implementations. Policy is an individual per-node decision, not something standardized in itself.

[darosior]

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.

[ajtowns]

The main policy change is making the script standard to create as an ouput. I think it's only that you're defining a new valid witness program (rather than using OP_TRUE directly) that means you also need to make spending standard.

[ajtowns]

Might want to emphasise here that dust limits do not apply?

[ajtowns]

Does this mean the bitcoin core PR should (does?) reject attempts to prioritisetransaction when it notices the tx being prioritised creates an EA output?

[ajtowns]

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.

[michaelfolkson]

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]

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.

[michaelfolkson]

@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.

[michaelfolkson]

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.

[jonatack]

Suggested change

	Type: Standards Track
	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.

[instagibbs]

done

[jonatack]

Note that this isn't one of the BIP123 / BIP2 classification layers. I'm not sure, but it looks like BIPs 2 and 123 would need to be updated if there is consensus on classifying BIPs as Mempool Policy layer.

[ajtowns]

BIP 125 (RBF) uses "Layer: Application" here. Having a standard here is pretty much about coordination between node behaviour ("this sort of tx will be relayed") and applications ("how do i make txs that will be relayed?") so that seems reasonable?

[instagibbs]

did @ajtowns suggestion for now

[jonatack]

(if this refers to https://twitter.com/remyers_)

Suggested change

	* Richard Meyers
	* Richard Myers

[instagibbs]

done

[instagibbs]

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: bitcoin/bitcoin#29001 (comment)