From rusty at rustcorp.com.au Tue Apr 20 00:53:26 2021 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 20 Apr 2021 10:23:26 +0930 Subject: [Lightning-dev] Recovery of Lightning channels without backups In-Reply-To: References: <87r1nztz4k.fsf@rustcorp.com.au> Message-ID: <87a6ptkc8p.fsf@rustcorp.com.au> Lloyd Fournier writes: > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell 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. OK, I tried to spec this out, to implement it. One issue is that you now can't sign the commitment_tx (or htlc_tx) without knowing the node's secret key (or, equivalently, knowing the tweaked key and being able to use the derivation scheme to untweak it). c-lightning currently does a round-trip to the signing daemon for this already, but it'd be nice to avoid requiring it. So I somewhat reluctantly added `commit_basepoint` from which the others are derived: an implementation can use some hardened derivation from its privkey (e.g. SHA256(node_privkey || ss || counter)) to create this in a deterministic but still private manner. Or we could just leave all the other points in and just replace funding_pubkey. Cheers, Rusty.