Lightning transactions with v3 and ephemeral anchors

[t-bast]

@morehouse

Yes, there’s some risk to the attacker. But as long as the attacker achieves a greater than 50% success rate, the pin pays off. Do we have strong evidence that an attacker cannot achieve that today?

No, I don’t have any evidence of that, and I think it’s really hard to evaluate! I honestly don’t know how feasible such an eclipse attack is. In this specific case it feels very hard to pull off, because lightning nodes should be running multiple independent bitcoin nodes that would let them easily monitor conflicting transactions (and thus learn preimages in that specific case). But I have no idea how to quantify the difficulty.

@morehouse

Yeah, we’d need a new message to transmit HTLC signatures prior to the commitment signature.

My gut feeling is that we should wait for PTLCs to do this work, because we most likely need something similar for PTLC to exchange partial signatures (as detailed in my old writeup with the commitment_proposed message).

Meanwhile, I think we can live with the simple mitigation of discovering the preimage in the mempool of our “backup” bitcoin nodes.

@ajtowns

At that point the channel funds may be difficult for Alice to access indefinitely, as far as I can see.

True, there is a potential for a griefing attack here. This is annoying, but not as terrible as an attack where Bob steals from Alice! Lightning node operators should configure their max_htlc_value_in_flight_msat to bound their exposure to that kind of attack: it’s not very satisfying, but is probably good enough in practice?

Long term we’ll eventually fix that, but we can probably live with it until then.

[morehouse]

@t-bast

@morehouse

Yeah, we’d need a new message to transmit HTLC signatures prior to the commitment signature.

My gut feeling is that we should wait for PTLCs to do this work, because we most likely need something similar for PTLC to exchange partial signatures (as detailed in my old writeup with the commitment_proposed message).

Cool! With the approach in your writeup, it looks like we can simply make the Claim-PTLC-Success transactions v3, with no other changes required.

Seems like a great way to kill two birds with one stone.

[instagibbs]

Sibling Eviction for v3 transactions

When we receive a transaction that would bust a mempool transaction’s descendant limits, we usually reject it (unless it is eligible for CPFP carve out). An alternative approach (e.g. when this transaction is very high feerate and it’d be a shame to let it go) is to consider evicting the least incentive compatible descendant in favor of this new transaction. That way we don’t compromise on our anti-DoS-motivated descendant limit (like we do with CPFP carve out), but don’t need to be stuck with …

this topic is relevant to discussion.

If we do sibling eviction more generally in v3:

1. “imbued” commitment transactions prior to any spec update would be RBF’ing other anchor spends, rather than using a carveout
2. you could go with a 330 sat (shared)keyed anchor, and still remove 1 CSV from all other scripts. Or have N anchors

in other words, ephemeral anchors would be about make anchors cheaper and potential separation of funds/fees, rather than the side benefit of sibling eviction.

You could also drop the ephemeral/keyed anchor in a commit tx in certain cases, like a commit tx with only the remote balance output left, and probably other cases.