Skip to content

Rebroadcast coop close transactions #2238

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
TheBlueMatt opened this issue Apr 27, 2023 · 8 comments
Open

Rebroadcast coop close transactions #2238

TheBlueMatt opened this issue Apr 27, 2023 · 8 comments
Labels
Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment

Comments

@TheBlueMatt
Copy link
Collaborator

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

@TheBlueMatt TheBlueMatt added this to the 0.1 milestone Apr 27, 2023
@wpaulino
Copy link
Contributor

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

@TheBlueMatt
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Contributor

wpaulino commented May 1, 2023

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@wpaulino
Copy link
Contributor

wpaulino commented May 1, 2023

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 TheBlueMatt removed this from the 0.1 milestone May 6, 2024
@TheBlueMatt TheBlueMatt added the Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment label May 6, 2024
@TheBlueMatt TheBlueMatt modified the milestone: 0.0.124 May 8, 2024
@TheBlueMatt
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Take a Friday Leave a Friday Stomp the Bugs, Without Much Commitment
Projects
None yet
Development

No branches or pull requests

2 participants