Hey Lloyd (and others), I have just been working on something similar. I came up with the following plan of attack that works within the current protocol:
Create a static channel backup after the fact. I have dubbed this a synthetic static channel backup. I only use it to trigger the data loss protection protocol. By restoring this synthetic SCB a `channel_reestablish` is being sent to the remote peer. This `channel_reestablish`contains the `next_commitment_number`and the `next_revocation_number` both set to zero. This triggers the remote peer to force close the channel dropping its current commitment transaction to the chain. Using the `per_commitment_point` received from the remote peer you can now derive the private key needed for sweeping your funds, using privkey = basepoint_secret + SHA256(per_commitment_point || basepoint) We use the basepoint_secret derived (in LND) with ``` basePointSecret, err := keyRing.DerivePrivKey(keychain.KeyDescriptor{ KeyLocator: keychain.KeyLocator{ Family: keychain.KeyFamilyPaymentBase, Index: 0, // Same commitment index as used by the remote node }, }) ``` I have got this somewhat working in a test setup. (I probably have overlooked some details). I would be interested in hearing Sjors Provoost on this, since his question and answer on this topic over on the Bitcoin StackExchange was really helpful.[1] He lost his backup in a boating accident as well. (What is it with you guys and boating? :) ) Your approach covers more cases, and my approach only fits certain edge cases. But my approach is possible today, without changes to the Lightning protocol. Regards, Gijs [1]: https://bitcoin.stackexchange.com/questions/90196/how-to-recover-funds-from-a-force-closed-lnd-lightning-channel/90719#90719 On Mon, Dec 7, 2020 at 8:32 AM Lloyd Fournier <lloyd.fo...@gmail.com> wrote: > Hi list, > > I've been considering the problem of recovering lightning channels after > losing channel state in a boating accident. The modern way of doing this > seems to be "static channel backups" -- these are essentially lists of > channel ids and the nodes you had the channels with. > > The idea is that with this backup you can remember who you had channels > with, connect to them and ask them to force close the channel (can someone > link me the concrete protocol messages you send to do this?). > > It occurred to me that if the lightning protocol were changed slightly you > could do this without the channel backup at all. Consider the open channel > message and its two fields `funding_pubkey` and `temporary_channel_id`. > > > https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message > > The reason `temporary_channel_id` is necessarily "temporary" is because we > don't know the other party's `funding_pubkey`. Instead I propose using > deterministically randomized version of the node's static public key as the > `funding_pubkey` so we know it up front. Specifically, when opening a > channel with a remote node, do a Diffie-Hellman operation with their public > key and use the resulting shared secret to deterministically produce > scalars r1 and r2 and use 2-of-2(r1*G + P_local, r2*P_remote) as the script > pubkey of funding output. Now we know what the funding output would look > like with any node without interacting with them. Of course, to open > multiple channels with the same node we would have to generate a new shared > secret from each one by hashing a counter. > > Now that we can figure out what our funding outputs with each node look > like non-interactively, when we lose our channel state we can find them in > the UTXO set as long as we can recreate a list of node's we may have had > channels with. For most non-enterprise users (such as myself) this can be > done automatically because we exclusively have channels with well known > reliable public nodes whose public keys can be discovered through routing > gossip or from public indexes. Therefore if I can just restore my node's > keypair from my seed I should be able to scan the network for nodes and > figure out if I have channels open with them and then carry out the > recovery process. From my perspective this seems to be a rather nice > improvement in user experience. > > Thoughts? > > Cheers, > > LL > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev