rich1.0Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypnjumphttps://yabu.me📅 Original date posted:2021-04-20 📝 Original message: Hi Rusty, On Tue, 20 Apr 2021 at 10:55, Rusty Russell <rusty at rustcorp.com.au> wrote: > 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). > Using node secret key to sign the commitment_tx seems like something you will have to accept to introduce this feature. For the idea to work it has to be some public key that is known by others and gossiped through the network. Of course you could extend the information that is gossiped about a node to include a "commit_tx_point" but the nodeid seems the more natural choice. > 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. > Another approach is to do things in "soft-fork" like manner. Each node that wants to offer this feature sets their funding_pubkey to a specified DH tweak of the nodeid. Nodes that want backup-free channel recovery can just refuse to carry on the funding protocol if the funding_pubkey is not set the way it wanted. >From my pruisit crypto point of view having only one public key is nice but I'm not sure how it impacts things architecturally and other protocols like watchtowers. Cheers, LL -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210420/65f16c10/attachment.html>