📅 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 12:39:53
in reply to nevent1q…50lt
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 12:39:53Event JSON
{
"id": "a604cf980a6e71f2c8bd09910393e4d6808f3b61bd9ef122d110d7768c52615b",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686314393,
"kind": 1,
"tags": [
[
"e",
"8d55efdb623b239cb06228bde5251431905fd7cf7a73e255edf010d2d1fd1ac2",
"",
"root"
],
[
"e",
"bb1febb8b93cbb2fbe6324b3945add8abc6705f83d81bf432178cf15a1e90f46",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2021-04-20\n📝 Original message:\nHi Rusty,\n\nOn Tue, 20 Apr 2021 at 10:55, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Lloyd Fournier \u003clloyd.fourn at gmail.com\u003e writes:\n\u003e \u003e On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)?\n\u003e \u003e\u003e\n\u003e \u003e\u003e Nice work. This would be a definite recovery win. We should add this\n\u003e \u003e\u003e to the DF spec, because Lisa was almost finished implmenting it, so it's\n\u003e \u003e\u003e clearly due for a change!\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e Yes that's certainly a fine way to do it.\n\u003e \u003e I was also thinking you could eliminate all \"basepoints\" (not just\n\u003e funding\n\u003e \u003e pubkey) using something like this. i.e. just use the node pubkey as the\n\u003e \u003e \"basepoint\" for everything and randomize it using the shared secret for\n\u003e \u003e each purpose.\n\u003e\n\u003e OK, I tried to spec this out, to implement it. One issue is that you\n\u003e now can't sign the commitment_tx (or htlc_tx) without knowing the node's\n\u003e secret key (or, equivalently, knowing the tweaked key and being able to\n\u003e use the derivation scheme to untweak it).\n\u003e\n\nUsing node secret key to sign the commitment_tx seems like something you\nwill have to accept to introduce this feature. For the idea to work it has\nto be some public key that is known by others and gossiped through the\nnetwork. Of course you could extend the information that is gossiped about\na node to include a \"commit_tx_point\" but the nodeid seems the more natural\nchoice.\n\n\n\u003e c-lightning currently does a round-trip to the signing daemon for this\n\u003e already, but it'd be nice to avoid requiring it.\n\u003e\n\u003e So I somewhat reluctantly added `commit_basepoint` from which the others\n\u003e are derived: an implementation can use some hardened derivation from its\n\u003e privkey (e.g. SHA256(node_privkey || ss || counter)) to create\n\u003e this in a deterministic but still private manner.\n\u003e\n\u003e Or we could just leave all the other points in and just replace\n\u003e funding_pubkey.\n\u003e\n\nAnother approach is to do things in \"soft-fork\" like manner.\nEach node that wants to offer this feature sets their funding_pubkey to a\nspecified DH tweak of the nodeid. Nodes that want backup-free channel\nrecovery can just refuse to carry on the funding protocol if the\nfunding_pubkey is not set the way it wanted.\n\n\u003eFrom my pruisit crypto point of view having only one public key is nice but\nI'm not sure how it impacts things architecturally and other protocols like\nwatchtowers.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210420/65f16c10/attachment.html\u003e",
"sig": "dee4fa54d8dc420b1e71955e89a3a27b8ba0d766dc4b07df123d2fbfa200bb6bc013f94c8ea41719d48f8f0f3bd0f4849eade26f3b7acbee448f3b670ed1f070"
}