search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.17k stars 367 forks source link

Rebroadcast coop close transactions #2238

Open TheBlueMatt opened 1 year ago

TheBlueMatt commented 1 year ago

Once we have a finalized coop close transaction we should consider rebroadcasting it via the channelmonitor, I think.

wpaulino commented 1 year ago

Would this be via ChannelMonitorUpdates or a more direct interface/API? We'll probably also need this for splicing.

TheBlueMatt commented 1 year ago

I think push it out via an update (we probably already do as a close once we shut down, or if not should?), and then rebroadcast in the monitor.

TheBlueMatt commented 1 year ago

So I had a coop close transaction that timed out of default mempools, and then eventually the normal rebroadcast kicked in and replaced it with a higher feerate unilateral close, which confirmed. That's probably actually a great, assuming the latest unilateral close has a higher feerate, so we should not break the current behavior when we do this.

wpaulino commented 1 year ago

How was the unilateral close broadcast? Did a restart happen after the coop close to trigger it? The unilateral close makes claiming your funds back more expensive, so even if it has a higher feerate, I would still prefer the coop close to confirm and CPFP that if I'm in a rush.

TheBlueMatt commented 1 year ago

I believe it was via the new rebroadcast paths in 115, but I didn't check the logs. This was only possible because the original coop close (which was not marked RBF) timed out of mempools (I think its after a week by default?). At that point we should probably broadcast whichever is higher fee rather than the coop one, I think?

TheBlueMatt commented 1 year ago

Or at least have an option to tell LDK to switch what its broadcasting.

wpaulino commented 1 year ago

Discussed this a bit offline, turns out the commitment was broadcast after a restart due to the channel no longer existing after the coop close. We should not be broadcasting the latest commitment in this case, unless the user does so explicitly. Instead, we should rebroadcast the coop close transaction as the issue mentions, and expose a way to bump its fees via CPFP (likely through the BumpTransactionEvent path).

TheBlueMatt commented 6 months ago

Not critical cuase we can always get our money back via FC, but its really dumb to require that.