📅 Original date posted:2020-12-06
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201207/5d78d233/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:01:41
in reply to nevent1q…w4gs
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:01:41Event JSON
{
"id": "be5d4f47b160b541d245a442c66d2ea3e72a58a9f67cb62e7e7e998d34adeedc",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315701,
"kind": 1,
"tags": [
[
"e",
"00d04f5d5dbc11371cafd7ab01bc802b993b222fe5855ee6daccf8136379e483",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-12-06\n📝 Original message:\nHi list,\n\nI've been considering the problem of recovering lightning channels after\nlosing channel state in a boating accident. The modern way of doing this\nseems to be \"static channel backups\" -- these are essentially lists of\nchannel ids and the nodes you had the channels with.\n\nThe idea is that with this backup you can remember who you had channels\nwith, connect to them and ask them to force close the channel (can someone\nlink me the concrete protocol messages you send to do this?).\n\nIt occurred to me that if the lightning protocol were changed slightly you\ncould do this without the channel backup at all. Consider the open channel\nmessage and its two fields `funding_pubkey` and `temporary_channel_id`.\n\nhttps://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message\n\nThe reason `temporary_channel_id` is necessarily \"temporary\" is because we\ndon't know the other party's `funding_pubkey`. Instead I propose using\ndeterministically randomized version of the node's static public key as the\n`funding_pubkey` so we know it up front. Specifically, when opening a\nchannel with a remote node, do a Diffie-Hellman operation with their public\nkey and use the resulting shared secret to deterministically produce\nscalars r1 and r2 and use 2-of-2(r1*G + P_local, r2*P_remote) as the script\npubkey of funding output. Now we know what the funding output would look\nlike with any node without interacting with them. Of course, to open\nmultiple channels with the same node we would have to generate a new shared\nsecret from each one by hashing a counter.\n\nNow that we can figure out what our funding outputs with each node look\nlike non-interactively, when we lose our channel state we can find them in\nthe UTXO set as long as we can recreate a list of node's we may have had\nchannels with. For most non-enterprise users (such as myself) this can be\ndone automatically because we exclusively have channels with well known\nreliable public nodes whose public keys can be discovered through routing\ngossip or from public indexes. Therefore if I can just restore my node's\nkeypair from my seed I should be able to scan the network for nodes and\nfigure out if I have channels open with them and then carry out the\nrecovery process. From my perspective this seems to be a rather nice\nimprovement in user experience.\n\nThoughts?\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201207/5d78d233/attachment.html\u003e",
"sig": "85ac8bb29c441a3d9ef210914dbc54c0a7811c340b301140e84e8eed8577bfc6c00830d34d2b9e658cbd94cf2c58061d00a6fb09cd45062ffda2cb44377508d3"
}