Lloyd Fournier <lloyd.fo...@gmail.com> writes: > 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's in BOLT #2: 1. type: 136 (`channel_reestablish`) 2. data: * [`channel_id`:`channel_id`] * [`u64`:`next_commitment_number`] * [`u64`:`next_revocation_number`] * [`32*byte`:`your_last_per_commitment_secret`] * [`point`:`my_current_per_commitment_point`] The `your_last_per_commitment_secret` lets Bob prove to Alice that he's from The Future, and prior to `option_static_remotekey` my_current_per_commitment_point allowed Alice to derive the script used for her output. > 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`. Hmm, we had a proposal (for DF) to get rid of the temporary_channel_id by using 'SHA256(lesser-revocation-basepoint || greater-revocation-basepoint)' as the channel_id, which is known from the start. I don't see it in the DF spec PR, but it's in c-lightning. > 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. Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? Nice work. This would be a definite recovery win. We should add this to the DF spec, because Lisa was almost finished implmenting it, so it's clearly due for a change! > 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. Note that in practice you can have nodes reconnecting to you. We've long thought about peers supplying some storage for each other, so you can spray out (encrypted) backups that way. It's actually a fairly trivial addition; your scheme makes for much less data to store. Cheers! Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
