On 09/14/2017 11:49 PM, Rusty Russell wrote: >>>> I guess I'm confused how this is going to work safely. If you >>>> put a refund request in with your payment, isn't that revealing the >>>> public key of your node and then defeating the whole purpose of the >>>> onion routing of the payment in the first place (I'm, assuming the payee >>>> node re-uses the same public key?)? It seems like rather than putting a >>>> >>> flag in BOLT 11 to instruct a payer to include a refund payment >>>> >>> request, >>>> >>> shouldn't the payer just know to do that if they think they will need >>>> >>> to? Or maybe they won't always? >>> >> Nobody along the route (B and C in our example above) can see it. And D >>> >> kind of has to, since it needs to send the refund. >> > >> > It seems to me like this is sort of a limitation in privacy with >> > lightening. With blockchain payments on my fuel pump, I could return a >> > refund back to the customer without always knowing who they are. With >> > lightning, it looks like the payer will reveal their identity to the >> > payee by offering a refund payment request. It's great that those along >> > the payment route don't know, but it's still bad to have the payer >> > revealed to the payee. Why does someone have to reveal their identity >> > just to get a refund? > Indeed, it's deeply suboptimal for privacy. > > There's a more complex scheme which is possible, using round-trip > payments (I think this was originally from Christian Decker?); I make a > payment via you and back to myself, it's just that I pay your node an > abnormally high "fee". But unfortunately for security reasons each > encrypted hop contains the amount it expects to be sent, which doesn't > work if I don't know how much you're going to refund. > > Technically, you can put a really small amount in there (each node only > insists that the amount sent is >= this amount), but this just allows > one of those return nodes to untracably steal the extra refund amount. > > So, we really need to be able to include a (smaller) return onion to > fix this properly. I've added that to: > > > https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#refunds > > Thanks! > Rusty.
If you are including a smaller return onion, you are including that with the payment? That return onion would be created by the payer since they know the routes from the payer to the payee? If so, how could this work if the route no longer has capacity (or goes down) by the time the payee decides it's going to send the refund back to the payer (which could be minutes, hours, or days later)? Also, even if all routes are still up, the payer may not necessarily know how much refund the payee will be giving them, so they may not necessarily be able to even know what the best route they should build an onion for? Andy Schroder _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
