On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell <ru...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
