📅 Original date posted:2021-10-13
📝 Original message:
Hi SomberNight,
I started a similar discussion less than a year ago on the list. The idea I
put forward works fine with MuSig and taproot.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html
The idea was considered for channel establishment v2 but in the end there
were various objections to it becoming specified as it forces
implementations to handle keys in a certain way. You can still do it
informally though by fixing your funding pubkey to be derived from the
Diffie-Hellman key of the two node ids. This makes the funding public keys
a (secret) deterministic function of the two node ids without making a
privacy leak.
FWIW I still think this is a good idea but in hindsight I think the
objections to it being mandatory are valid.
Cheers,
LL
On Sat, 18 Sept 2021 at 02:14, SomberNight via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> TL;DR: an approach is described how to derive channel keys
> deterministically that allows certain forms of recovery from just
> a seed, that works today. This approach however will no longer work
> with e.g. MuSig key aggregation in the future. An idea for a proposal
> is given how the channel-open flow (e.g. as part of channel v2) could be
> changed to make a similar approach work independent of key aggregation.
>
> -----
>
> While implementing anchor output support in Electrum, we have realised
> one difficulty is to do with the remote-force-close case where the
> to_remote output is no longer a simple p2wpkh.
>
> Currently, pre-anchor-support, Electrum sets option_static_remotekey
> to required (feature bit 12), and we restrict lightning usage to wallets
> that derive p2wpkh addresses, and payment_basepoint is set
> to a bip32-derived pubkey that corresponds to a wallet address.
> Hence, if a user were to restore from seed words, and their channel
> counterparty force closed their channel, the to_remote output of the
> broadcast commitment tx would directly pay to the user's wallet.
> That is, in many typical scenarios, funds are not lost when restoring
> from seed.
>
> (Also, if we are the channel-funder/opener, it is easy to find the
> funding transaction, just by testing txs in the wallet history.
> Further, for the cases we are the channel-funder/opener,
> there is a setting to put an OP_RETURN in the funding tx, which stores
> the nodeid of the counterparty, allowing us to identify who to contact
> to get the channel closed.
> Also, we are (ab)using dataloss_protect to ask the remote
> to force-close when restoring from seed, so the user does not even have
> to wait for an arbitrarily long time.)
>
> With anchors, the to_remote is now a p2wsh that involves a CSV,
> and we cannot easily make this script correspond to a wallet address,
> i.e. we lose the property that the remote-force-close pays directly
> to a wallet address.
>
> So, the problem we would like to solve, is:
> - having seed words
> - having access to blockchain data
> - somehow having identified our channel counterparties (node IDs),
> and our channels with them (funding outpoints)
> - and assuming we can get the remote to do a force-close
> --> we would like to be able to spend the to_remote output
>
> Solutions:
>
> 1) Naively, we could just derive a static key to be used as
> payment_basepoint, reused between all our channels, and watch the
> single resulting p2wsh script on-chain.
> Clearly this has terrible privacy implications.
>
> 2) Or, we could derive a new bip32 chain/sequence of pubkeys
> used as payment_basepoint for channels, and watch these p2wsh scripts,
> with a gap limit.
> Particularly the gap limit part makes this undesirable though
> (just consider having more than "gap limit" channels open and restoring
> from seed).
>
> Instead, it seems desirable to see whether we can extract some entropy
> from the blockchain, and use that as a nonce to be combined with a
> static private secret derived from our seed.
> We could extract data either from the funding tx, or from the
> remote-commitment-transaction that spent the funding output.
>
> 3) We exploit the fact that the funding output uses a
> 2of2 OP_CHECKMULTISIG script composed of the funding pubkeys of
> each party. The funding pubkey itself can be used as a nonce, and
> it can be recovered from the witness of the commitment tx.
> The privkey for payment_basepoint can then be derived as e.g.
> hash(bip32_derive(seed, HARDCODED_PATH) + funding_pubkey).
>
> In fact (3) is not novel at all: eclair has been deriving
> all their channel keys like this [0] for some time, from
> a static seed-based secret combined with the funding_pubkey as nonce,
> and generating the funding_privkey from ~os.urandom.
>
> Electrum will likely use (3) at least for the payment_basepoint,
> as part of adapting to anchors.
>
> -----
>
> Note that the idea (3) relies on recovering the funding_pubkey from
> the witness of the spending transaction, which will break in the future
> if the funding script is changed to e.g. a p2tr that uses musig.
>
> Crucially, note that all the approach needs is some blockchain-visible
> nonce that is already known at the time we need to construct the
> open_channel message (as we want to be able to derive some of the keys
> that are sent as part of the open_channel message
> (e.g. payment_basepoint) from it).
> As long as the funding output uses a 2of2 OP_CHECKMULTISIG,
> the local funding_pubkey fits the bill.
>
> Note that irrespective of any restrictions on the script used in
> the funding output, we could use the funding scriptPubKey/address as
> the nonce, if the open_channel/accept_channel messages were
> split into two.
> For example, instead of the single round of open_channel/accept_channel,
> there could be two rounds:
> - an open_channel_part1, where the peers exchange only
> the funding_pubkey (and the other non-pubkey fields), and
> - an open_channel_part2, where the rest of the pubkeys are sent
> This way the peers would learn what the funding address would be after
> the first round finishes, and could potentially use that to derive
> their other channel keys (needed for round 2).
>
> So, to arrive at my point, I would like to ask whether people think
> such a change - or something similar - might be useful, and if so,
> whether it could/should be incorporated to the current
> channel establishment v2 proposal [1].
> If there is agreement that this would be useful, a spec change
> would be most useful before changing the 2of2 multisig script.
>
> Regards,
> ghost43 (SomberNight)
>
>
> [0]: https://github.com/ACINQ/eclair/pull/1097
> [1]: https://github.com/lightningnetwork/lightning-rfc/pull/851
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/390ec20d/attachment-0001.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:04:16
in reply to nevent1q…kcwd
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:04:16Event JSON
{
"id": "6fcb1c4ae391263582dac6b4299d44f8586b949f5947e04632537c5f2c1839b6",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315856,
"kind": 1,
"tags": [
[
"e",
"bf9ed0fb67cf1475a2ae110dd64b97c7c548421761f55834230b2c64db7b777b",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2021-10-13\n📝 Original message:\nHi SomberNight,\n\nI started a similar discussion less than a year ago on the list. The idea I\nput forward works fine with MuSig and taproot.\n\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html\n\nThe idea was considered for channel establishment v2 but in the end there\nwere various objections to it becoming specified as it forces\nimplementations to handle keys in a certain way. You can still do it\ninformally though by fixing your funding pubkey to be derived from the\nDiffie-Hellman key of the two node ids. This makes the funding public keys\na (secret) deterministic function of the two node ids without making a\nprivacy leak.\n\nFWIW I still think this is a good idea but in hindsight I think the\nobjections to it being mandatory are valid.\n\nCheers,\n\nLL\n\nOn Sat, 18 Sept 2021 at 02:14, SomberNight via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e TL;DR: an approach is described how to derive channel keys\n\u003e deterministically that allows certain forms of recovery from just\n\u003e a seed, that works today. This approach however will no longer work\n\u003e with e.g. MuSig key aggregation in the future. An idea for a proposal\n\u003e is given how the channel-open flow (e.g. as part of channel v2) could be\n\u003e changed to make a similar approach work independent of key aggregation.\n\u003e\n\u003e -----\n\u003e\n\u003e While implementing anchor output support in Electrum, we have realised\n\u003e one difficulty is to do with the remote-force-close case where the\n\u003e to_remote output is no longer a simple p2wpkh.\n\u003e\n\u003e Currently, pre-anchor-support, Electrum sets option_static_remotekey\n\u003e to required (feature bit 12), and we restrict lightning usage to wallets\n\u003e that derive p2wpkh addresses, and payment_basepoint is set\n\u003e to a bip32-derived pubkey that corresponds to a wallet address.\n\u003e Hence, if a user were to restore from seed words, and their channel\n\u003e counterparty force closed their channel, the to_remote output of the\n\u003e broadcast commitment tx would directly pay to the user's wallet.\n\u003e That is, in many typical scenarios, funds are not lost when restoring\n\u003e from seed.\n\u003e\n\u003e (Also, if we are the channel-funder/opener, it is easy to find the\n\u003e funding transaction, just by testing txs in the wallet history.\n\u003e Further, for the cases we are the channel-funder/opener,\n\u003e there is a setting to put an OP_RETURN in the funding tx, which stores\n\u003e the nodeid of the counterparty, allowing us to identify who to contact\n\u003e to get the channel closed.\n\u003e Also, we are (ab)using dataloss_protect to ask the remote\n\u003e to force-close when restoring from seed, so the user does not even have\n\u003e to wait for an arbitrarily long time.)\n\u003e\n\u003e With anchors, the to_remote is now a p2wsh that involves a CSV,\n\u003e and we cannot easily make this script correspond to a wallet address,\n\u003e i.e. we lose the property that the remote-force-close pays directly\n\u003e to a wallet address.\n\u003e\n\u003e So, the problem we would like to solve, is:\n\u003e - having seed words\n\u003e - having access to blockchain data\n\u003e - somehow having identified our channel counterparties (node IDs),\n\u003e and our channels with them (funding outpoints)\n\u003e - and assuming we can get the remote to do a force-close\n\u003e --\u003e we would like to be able to spend the to_remote output\n\u003e\n\u003e Solutions:\n\u003e\n\u003e 1) Naively, we could just derive a static key to be used as\n\u003e payment_basepoint, reused between all our channels, and watch the\n\u003e single resulting p2wsh script on-chain.\n\u003e Clearly this has terrible privacy implications.\n\u003e\n\u003e 2) Or, we could derive a new bip32 chain/sequence of pubkeys\n\u003e used as payment_basepoint for channels, and watch these p2wsh scripts,\n\u003e with a gap limit.\n\u003e Particularly the gap limit part makes this undesirable though\n\u003e (just consider having more than \"gap limit\" channels open and restoring\n\u003e from seed).\n\u003e\n\u003e Instead, it seems desirable to see whether we can extract some entropy\n\u003e from the blockchain, and use that as a nonce to be combined with a\n\u003e static private secret derived from our seed.\n\u003e We could extract data either from the funding tx, or from the\n\u003e remote-commitment-transaction that spent the funding output.\n\u003e\n\u003e 3) We exploit the fact that the funding output uses a\n\u003e 2of2 OP_CHECKMULTISIG script composed of the funding pubkeys of\n\u003e each party. The funding pubkey itself can be used as a nonce, and\n\u003e it can be recovered from the witness of the commitment tx.\n\u003e The privkey for payment_basepoint can then be derived as e.g.\n\u003e hash(bip32_derive(seed, HARDCODED_PATH) + funding_pubkey).\n\u003e\n\u003e In fact (3) is not novel at all: eclair has been deriving\n\u003e all their channel keys like this [0] for some time, from\n\u003e a static seed-based secret combined with the funding_pubkey as nonce,\n\u003e and generating the funding_privkey from ~os.urandom.\n\u003e\n\u003e Electrum will likely use (3) at least for the payment_basepoint,\n\u003e as part of adapting to anchors.\n\u003e\n\u003e -----\n\u003e\n\u003e Note that the idea (3) relies on recovering the funding_pubkey from\n\u003e the witness of the spending transaction, which will break in the future\n\u003e if the funding script is changed to e.g. a p2tr that uses musig.\n\u003e\n\u003e Crucially, note that all the approach needs is some blockchain-visible\n\u003e nonce that is already known at the time we need to construct the\n\u003e open_channel message (as we want to be able to derive some of the keys\n\u003e that are sent as part of the open_channel message\n\u003e (e.g. payment_basepoint) from it).\n\u003e As long as the funding output uses a 2of2 OP_CHECKMULTISIG,\n\u003e the local funding_pubkey fits the bill.\n\u003e\n\u003e Note that irrespective of any restrictions on the script used in\n\u003e the funding output, we could use the funding scriptPubKey/address as\n\u003e the nonce, if the open_channel/accept_channel messages were\n\u003e split into two.\n\u003e For example, instead of the single round of open_channel/accept_channel,\n\u003e there could be two rounds:\n\u003e - an open_channel_part1, where the peers exchange only\n\u003e the funding_pubkey (and the other non-pubkey fields), and\n\u003e - an open_channel_part2, where the rest of the pubkeys are sent\n\u003e This way the peers would learn what the funding address would be after\n\u003e the first round finishes, and could potentially use that to derive\n\u003e their other channel keys (needed for round 2).\n\u003e\n\u003e So, to arrive at my point, I would like to ask whether people think\n\u003e such a change - or something similar - might be useful, and if so,\n\u003e whether it could/should be incorporated to the current\n\u003e channel establishment v2 proposal [1].\n\u003e If there is agreement that this would be useful, a spec change\n\u003e would be most useful before changing the 2of2 multisig script.\n\u003e\n\u003e Regards,\n\u003e ghost43 (SomberNight)\n\u003e\n\u003e\n\u003e [0]: https://github.com/ACINQ/eclair/pull/1097\n\u003e [1]: https://github.com/lightningnetwork/lightning-rfc/pull/851\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211013/390ec20d/attachment-0001.html\u003e",
"sig": "d6e457ec30b9151771f8f64fdb67c18b917504f658ac460185d78c14db7cf4747237f39fcc8f9cdf78a759480a0e06ae216ffba9c323b72fcfb641c64e235d01"
}