📅 Original date posted:2018-02-22
📝 Original message:
Hi Corné!
Indeed, the privacy focus has generally been the payer, rather
than the recipient of funds.
So there are several things we can do to address this, the main
obvious one the ability to provide a "pre-cooked" onion. This would
allow either a payment to an anonymous destination directly or via a
middleman who has that pre-cooked onion.
I'm pretty sure we can't do this *now*: the shared secrets
required for decoding error replies allow you to to decrypt the entire
onion, AFAICT. At a minimum, we need errors from the final destination
so we can reflect them. I believe a simple tweak to use the SHA256() of
the secrets for shared secret used to encrypt the error replies would
allow this: you would provide those error secrets along with the onion.
> What are your ideas on this? Should proof of payment be optional? Should
> its strength (optionally) be reduced, so that it can only be used in
> front of some previously-agreed-on dispute resolution party (is that
> even possible)? Should the idea of proof of payment be abandoned
> altogether? Is bi-directional routing(*) useful in this?
The proof-of-payment here is a red herring, I think. If we remove the
destination awareness, the privacy issues seem greatly reduced.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:49:12
in reply to nevent1q…65r5
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:49:12Event JSON
{
"id": "7768639d8cd3f8f124506fa848007b808a6a043a0e91c6151f4aeede8f2e3508",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314952,
"kind": 1,
"tags": [
[
"e",
"16b61f0ab222252050310ae91858d7a1fb5016038f520e088915c7faef90c1f7",
"",
"root"
],
[
"e",
"c034b17d231f6917088356aa2819d5eda39d01a8efb3f2f372d8301504f00932",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-02-22\n📝 Original message:\nHi Corné!\n\n Indeed, the privacy focus has generally been the payer, rather\nthan the recipient of funds.\n\n So there are several things we can do to address this, the main\nobvious one the ability to provide a \"pre-cooked\" onion. This would\nallow either a payment to an anonymous destination directly or via a\nmiddleman who has that pre-cooked onion.\n\n I'm pretty sure we can't do this *now*: the shared secrets\nrequired for decoding error replies allow you to to decrypt the entire\nonion, AFAICT. At a minimum, we need errors from the final destination\nso we can reflect them. I believe a simple tweak to use the SHA256() of\nthe secrets for shared secret used to encrypt the error replies would\nallow this: you would provide those error secrets along with the onion.\n\n\u003e What are your ideas on this? Should proof of payment be optional? Should\n\u003e its strength (optionally) be reduced, so that it can only be used in\n\u003e front of some previously-agreed-on dispute resolution party (is that\n\u003e even possible)? Should the idea of proof of payment be abandoned\n\u003e altogether? Is bi-directional routing(*) useful in this?\n\nThe proof-of-payment here is a red herring, I think. If we remove the\ndestination awareness, the privacy issues seem greatly reduced.\n\nCheers,\nRusty.",
"sig": "0422c0c798c2431a014812991bb33e70b67f572f3bbe98d25181622648c82138e62315d7fa6f6d4047e7e36d9b35d2e2d2669e0a928560586f19f6b58c48ffec"
}