Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-09 📝 Original message: > Create a static channel ...
📅 Original date posted:2020-12-09
📝 Original message:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201209/22894c20/attachment.html>;
📝 Original message:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201209/22894c20/attachment.html>;