Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-19 📝 Original message: Lloyd Fournier ...
📅 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.
📝 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.