Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-10 📝 Original message: On Wed, Dec 9, 2020 at ...
📅 Original date posted:2020-12-10
📝 Original message:
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> 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!
>
Yes that's certainly a fine way to do it.
I was also thinking you could eliminate all "basepoints" (not just funding
pubkey) using something like this. i.e. just use the node pubkey as the
"basepoint" for everything and randomize it using the shared secret for
each purpose.
Note that in practice you can have nodes reconnecting to you.
>
Hmm, this is a good point.
I was incorrectly assuming the best way to implement "recovery mode" would
be to never accept incoming connections.
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.
>
I've also been thinking about the best way to go about this.
If you're able to encrypt some backups to different places then all you
have to do is find one of your honest channel partners using this method
and then get encrypted hints to find them all.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201210/28068208/attachment.html>;
📝 Original message:
On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <rusty at rustcorp.com.au> wrote:
>
> 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!
>
Yes that's certainly a fine way to do it.
I was also thinking you could eliminate all "basepoints" (not just funding
pubkey) using something like this. i.e. just use the node pubkey as the
"basepoint" for everything and randomize it using the shared secret for
each purpose.
Note that in practice you can have nodes reconnecting to you.
>
Hmm, this is a good point.
I was incorrectly assuming the best way to implement "recovery mode" would
be to never accept incoming connections.
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.
>
I've also been thinking about the best way to go about this.
If you're able to encrypt some backups to different places then all you
have to do is find one of your honest channel partners using this method
and then get encrypted hints to find them all.
Cheers,
LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201210/28068208/attachment.html>;