Lloyd Fournier <lloyd.fo...@gmail.com> writes: > 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.
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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
