{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 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"}