rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2021-04-19 📝 Original message: Lloyd Fournier <lloyd.fourn at gmail.com> writes: > 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. 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.