📅 Original date posted:2019-12-20
📝 Original message:
Indeed, please excuse the brevity of my proposed mechanism and my basic
cryptographic toolkit. Thank you for building on it!
The additional cost in the closing transaction would be an interesting
trade-off for the privacy it provides. It could be negotiated on channel
opening alongside the fee structure. I brought it up because it would be
interesting to discuss this privacy improvement because it can be
implemented today, and phased out when viable.
I am worried that it might open the door for an entropy exhaustion attack
on negotiation, yet that might be easy to prevent.
E
On Fri, 20 Dec 2019 at 13:40 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Esteban,
>
> > On Fri, Dec 20, 2019 at 12:59 PM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > > Current Lightning Network mutual closes are spends of 2-of-2 outputs.
> > > Given that most people will use either 1-of-1 or 2-of-3 ("never go to
> sea with two chronometers, take one or three"), they stand out and it is
> reasonable to assume that any 2-of-2 will be Lightning.
> >
> > Interesting... alternatively, one could explore modifying the current
> 2-of-2 closing outputs to make them undistinguishable from 2-of-3 outputs
> by negotiating a random third public key with a nonexistent private key
> (like XORing random values provided by each channel participant).
>
> It has the drawback of requiring three public keys in the resulting
> revealed SCRIPT rather than two.
> Further, *hopefully* the incoming BIP-Schnorr, with *hopefully* upcoming
> improvements in the verifiable secret splitting thing, will allow "normal"
> MuSig 2-of-2 to be indistinguishable from 2-of-3 as well.
>
> It would be best to have a standardized NUMS point, then have both
> participants add their own one-time points to that point, precommitting
> hashes of those points first, then providing the points, then generating
> the sum of standard NUMS plus their random points.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191220/b0589629/attachment.html>;
Esteban Ordano [ARCHIVE] /
npub17j…afegv
2023-06-09 12:57:52
in reply to nevent1q…l83m
Author Public Key
npub17j02l73ccsq8utw8krqphx5rjklrxua4xnmf73wss2nnndvcy4fquafegvSeen on
wss://relay.nostr.bandPublished at
2023-06-09 12:57:52Event JSON
{
"id": "fd9875898dca700186bf39f6ccb711b387ba04ec294eca2a8d9e634aab0e53f2",
"pubkey": "f49eaffa38c4007e2dc7b0c01b9a8395be3373b534f69f45d082a739b5982552",
"created_at": 1686315472,
"kind": 1,
"tags": [
[
"e",
"1499f1bac287e8f0a1420b153db788b2492f8e8fe152b6bb231933ec6575b64d",
"",
"root"
],
[
"e",
"850e6a8fe315ec1e4a2b30f9ba10b7bd194673ebdd0dc3363b69ed3036e0fae7",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2019-12-20\n📝 Original message:\nIndeed, please excuse the brevity of my proposed mechanism and my basic\ncryptographic toolkit. Thank you for building on it!\n\nThe additional cost in the closing transaction would be an interesting\ntrade-off for the privacy it provides. It could be negotiated on channel\nopening alongside the fee structure. I brought it up because it would be\ninteresting to discuss this privacy improvement because it can be\nimplemented today, and phased out when viable.\n\nI am worried that it might open the door for an entropy exhaustion attack\non negotiation, yet that might be easy to prevent.\n\nE\n\nOn Fri, 20 Dec 2019 at 13:40 ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning Esteban,\n\u003e\n\u003e \u003e On Fri, Dec 20, 2019 at 12:59 PM ZmnSCPxj via Lightning-dev \u003c\n\u003e lightning-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Current Lightning Network mutual closes are spends of 2-of-2 outputs.\n\u003e \u003e \u003e Given that most people will use either 1-of-1 or 2-of-3 (\"never go to\n\u003e sea with two chronometers, take one or three\"), they stand out and it is\n\u003e reasonable to assume that any 2-of-2 will be Lightning.\n\u003e \u003e\n\u003e \u003e Interesting... alternatively, one could explore modifying the current\n\u003e 2-of-2 closing outputs to make them undistinguishable from 2-of-3 outputs\n\u003e by negotiating a random third public key with a nonexistent private key\n\u003e (like XORing random values provided by each channel participant).\n\u003e\n\u003e It has the drawback of requiring three public keys in the resulting\n\u003e revealed SCRIPT rather than two.\n\u003e Further, *hopefully* the incoming BIP-Schnorr, with *hopefully* upcoming\n\u003e improvements in the verifiable secret splitting thing, will allow \"normal\"\n\u003e MuSig 2-of-2 to be indistinguishable from 2-of-3 as well.\n\u003e\n\u003e It would be best to have a standardized NUMS point, then have both\n\u003e participants add their own one-time points to that point, precommitting\n\u003e hashes of those points first, then providing the points, then generating\n\u003e the sum of standard NUMS plus their random points.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191220/b0589629/attachment.html\u003e",
"sig": "4bfb0a6c8ea4ff0fe6ad10e34b7105b931f96177a6952d1ff7689456c0ed0cdf0fb5644c0e8a1c536464fbeec777c1db8e71358316900f6902609b2390bd7a4c"
}