Skip to content
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

[feature]: force close directly to wallet's address, taking anchors into account #8088

Closed
starius opened this issue Oct 12, 2023 · 2 comments
Labels
enhancement Improvements to existing features / behaviour

Comments

@starius
Copy link
Collaborator

starius commented Oct 12, 2023

Problem

If remote party broadcasts a force close transaction, local funds are sent to an intermediate output, which then is swept to the wallet.

If the local node has lost everything but seed, it won't be able to recover funds through remote force close transactions. Otherwise it could find the other node and ask to force close the channel.

If the local node doesn't have channel.backup, but has channel.db, it may use chantools rescueclosed and recover funds. But still getting funds directly would be more convenient and more reliable.

Also the additional sweep transaction means more fees. Even if a node works well, it still has to pay this fee every time another node broadcasts a force close transaction.

Solution

I propose to use an address from the wallet directly instead of creating an intermediate output. If this is implemented, then only the party initiated the force closing will have to make a sweep transaction, while the passive party will receive its funds in the wallet directly. This will save fees and prevent loss of funds if only seed is available.

Anchors

I found this discussion #6855 (comment)

  • With STATIC_REMOTE_KEY channels (which is the default if you don't have anchor channels activated) the above is not necessary. But we never updated the sweeper logic (changes to the channel state machine are always high risk!) to skip the extra sweep. Also, the keys of the to_remote output aren't in the BIP84 key scope so they wouldn't be discovered by the wallet recovery if you recovered from seed. So it's still necessary to sweep them to safety (until we fix recovery/btcwallet: detect funds in tweakless/static_remote output addresses on wallet recovery #4778).
  • With anchor output channels we now have a script in the to_remote, so it becomes crucial to sweep them again, as the script isn't included in the seed.

So, my proposal depends on fixing the wallet scanner to detect extra HD wallet derivation paths. Then such a path can be used for direct outputs of force close channels (one address per channel).

If a channel has anchor outputs, all non-anchor outputs must have 1 OP_CHECKSEQUENCEVERIFY (CSV). The wallet can have a path with such addresses! It is a normal P2WSH address, except it has 1 OP_CHECKSEQUENCEVERIFY (CSV) in the script. P2WSH witness scripts of such outputs currently look like this:

OP_PUSHBYTES_33 some_public_key
OP_CHECKSIGVERIFY
OP_PUSHNUM_1
OP_CSV

The public key is the only variable part. Private keys can be "stored" in seed using a separate HD wallet derivation path. If a channel is force closed by remote party, the local party doesn't have to do anything with these funds until it wants to spend them (e.g. open another channel).

@starius starius added the enhancement Improvements to existing features / behaviour label Oct 12, 2023
@Roasbeef
Copy link
Member

IIUC, we're tracking this here: #4778.

Perhaps port this OP comment into that issue so we can track in a single place?

@starius
Copy link
Collaborator Author

starius commented Oct 12, 2023

@Roasbeef Done

This issue can be closed then?

@guggero guggero closed this as completed Oct 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements to existing features / behaviour
Projects
None yet
Development

No branches or pull requests

3 participants