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
