📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:39:53
in reply to nevent1q…6kxy
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:39:53Event JSON
{
"id": "bb1febb8b93cbb2fbe6324b3945add8abc6705f83d81bf432178cf15a1e90f46",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314393,
"kind": 1,
"tags": [
[
"e",
"8d55efdb623b239cb06228bde5251431905fd7cf7a73e255edf010d2d1fd1ac2",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-04-19\n📝 Original message:\nLloyd Fournier \u003clloyd.fourn at gmail.com\u003e writes:\n\u003e On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?\n\u003e\u003e\n\u003e\u003e Nice work. This would be a definite recovery win. We should add this\n\u003e\u003e to the DF spec, because Lisa was almost finished implmenting it, so it's\n\u003e\u003e clearly due for a change!\n\u003e\u003e\n\u003e\n\u003e Yes that's certainly a fine way to do it.\n\u003e I was also thinking you could eliminate all \"basepoints\" (not just funding\n\u003e pubkey) using something like this. i.e. just use the node pubkey as the\n\u003e \"basepoint\" for everything and randomize it using the shared secret for\n\u003e each purpose.\n\nOK, I tried to spec this out, to implement it. One issue is that you\nnow can't sign the commitment_tx (or htlc_tx) without knowing the node's\nsecret key (or, equivalently, knowing the tweaked key and being able to\nuse the derivation scheme to untweak it).\n\nc-lightning currently does a round-trip to the signing daemon for this\nalready, but it'd be nice to avoid requiring it.\n\nSo I somewhat reluctantly added `commit_basepoint` from which the others\nare derived: an implementation can use some hardened derivation from its\nprivkey (e.g. SHA256(node_privkey || ss || counter)) to create\nthis in a deterministic but still private manner.\n\nOr we could just leave all the other points in and just replace\nfunding_pubkey.\n\nCheers,\nRusty.",
"sig": "1d46c43989bf25099f16ba45b1fac5f81ca12e38836ce15836585045a9c5522ac2d0e2c60774c5663ebbf7ab3e4ac66eac7879fd408a5dd8585c40ba0ef54a76"
}