Only skip bumping channel closes for trusted peers #461
Conversation
Previously, we'd skip handling any `BumpTransactionEvent` if the counterparty was trusted. However, this might result in funds getting stolen by the counterparty in the `ContentiousClaimable` case, as the counterparty is never expected to spend these back to us. Here, we therefore begin only skipping the bump events for the `ChannelClose` variant, and always try to claim funds requiring `HTLCResolution`.
tnull
force-pushed
the
2025-02-bump-on-htlcresolution-nonetheless
branch
from
5fd281c to
7a36e5b
Compare
nit: its not strictly "stealing", in the common case I'd imagine the counterparty fails back to the sender so the payment simply never completed. |
Noted, will probably leave as is since the 'mistake' is only in the commit/PR description. |
| self.config.anchor_channels_config.as_ref() | ||
| { | ||
| if anchor_channels_config | ||
| .trusted_peers_no_reserve |
There was a problem hiding this comment.
Should this be renamed now? You will need a reserve to handle the HTLC events. I guess you could use the to_remote funds from the confirmed commitment, but I'm not sure if ldk-node is wired up to do so.
There was a problem hiding this comment.
Should this be renamed now? You will need a reserve to handle the HTLC events.
Well, the no_reserve part refers to the fact that we don't account for these peers when calculating how much reserve we should keep. Essentially, the change in this PR makes the HTLCResolution case behave similar to setting the reserve to Some(0): we'd try to handle the events if we have funds, but don't keep a dedicated reserve for them.
I guess you could use the to_remote funds from the confirmed commitment, but I'm not sure if ldk-node is wired up to do so.
Yeah, I don't think there is a way to do this in LDK generally, as the respective events are entirely separate? I guess now, if we wouldn't have any reserve, we would still first sweep the commitment tx and then once the sweep confirms would be able to still reuse the funds to sweep the HTLC claim? FWIW, that might be yet another motivation for finally allowing to override payment_key to get rid of the additional sweep.
There was a problem hiding this comment.
I guess now, if we wouldn't have any reserve, we would still first sweep the commitment tx and then once the sweep confirms would be able to still reuse the funds to sweep the HTLC claim?
Yeah, it would take a few blocks to happen though since we wait for 6 confs on the commitment to yield the spendable output descriptor, plus however long that spend takes to confirm. By then, we may have lost the HTLC to the counterparty already.
FWIW, that might be yet another motivation for finally allowing to override payment_key to get rid of the additional sweep.
It ties your current L1 wallet to the L2 state, which might not be ideal if you want to switch your L1 wallet (e.g., upgrading to a taproot-based wallet, compromised keys, etc.) while still keeping your L2 state intact. We would probably also want the ability to dynamically change payment_key at the protocol level, likely using quiescence.
3 participants
Previously, we'd skip handling any
BumpTransactionEventif the counterparty was trusted. However, this might result in funds getting stolen by the counterparty in theContentiousClaimablecase, as the counterparty is never expected to spend these back to us. Here, we therefore begin only skipping the bump events for theChannelClosevariant, and always try to claim funds requiringHTLCResolution.