> 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) >
Thanks Gijs for describing how this works I wasn't quite sure. The thing I dream of is being able to securely restore my layer 1 and 2 funds with just my seed. There was discussion of this idea in last lightning dev meeting: https://github.com/lightningnetwork/lightning-rfc/issues/821#issuecomment-740161185 A few of the concerns were: 1. You have to remember the counter The intention here is to not have to remember any counter. Just as in BIP32 you just scan with some allowance for gaps. roasbeef correctly points out that this may be more or less difficult depending on your node setup and whether you can ballpark how long ago your funding transactions were put down. However since you are using this when you have lost your channel states with no static channel backups I think it still provides a very realistic chance of recovering a significant chunk of your funds. Another point ariard made is that you only have to find one of the channels with a peer to find all of them with a peer if there was some kind of "list channels" message request. 2. It only works for public nodes who can be discovered Correct. For my use of LN so far I am always connecting to public nodes so it would likely work well for me. I think this is true for most unsophisticated users who are most likely to lose their channels with no backups. If each peer allowed you to store some encrypted data with them then finding one honest public peer through the chain could potentially let you find all other peers (even the private ones). 3. We might not want to encourage doing channel recovery by asking the node to force close channel I agree. "PLEASE BLACKMAIL ME" is not a bad characterization of the channel backup interaction Gijs describes above. I believe there is a lot of room for improvement here. First you have to find the channels though! LL
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
