Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-22 📝 Original message: Hi Corné! Indeed, the ...
📅 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.
📝 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.