Corné Plooy [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-21 📝 Original message: Hi, I am a bit concerned ...
📅 Original date posted:2018-02-21
📝 Original message:
Hi,
I am a bit concerned with the privacy implications of having either a
signed invoice + pre-image, or possibly a more powerful proof-of-payment
mechanism. In particular, I am concerned that it might provide
cryptographic evidence to the buyer that a certain seller performed the
transaction, and/or evidence to the seller that a certain buyer
performed the transaction.
In many cases, providing this evidence would be a feature rather than a
bug, allowing third-party dispute settlement (e.g. the legal system).
However, in my opinion, the Lightning network should also (or
especially) be suitable for more "sensitive" transactions. Even when
transactions are not illegal, I believe people still have a need to keep
some transaction information private. You don't want it to be possible
that your transaction history is stored on some company/person's server
for years, and then leaks out when that server gets hacked. Also, in my
opinion, we should *not* create a two-tier system of "sensitive" and
"nothing-to-hide" transactions: that would make the "sensitive"
transactions automatically suspicious, partially negating the whole
objective of being able to do sensitive transactions without
experiencing negative consequences.
To some degree, node IDs can act as pseudonyms, without evidence that
ties them to physical identities. However, I consider them to be
relatively poor pseudonyms: unlike, for instance, Bitcoin addresses,
creating a new node for every new transaction would have a serious
scalability impact, and defeat the whole purpose of Lightning. I think a
typical person would frequently perform transactions that are inherently
tied to their physical identity, e.g. receiving salary. This could give
the counterparty (the employer) a link between physical ID and node ID;
it might be forced to share this e.g. with authorities, further
increasing the odds of leak-out and/or abuse of data.
Maybe the solution is to have multiple nodes: one tied to your physical
ID, and one or more virtual identities? You could then transfer funds
between these nodes, and make sure no outsiders receive any
proof-of-payment info about these transfers. It sounds like an expensive
solution though, since you'd have to operate more channels to give each
node good connectivity.
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?
CJP
(*) Payee first finds a route from a rendezvous node to himself,
onion-encrypts that route, passes it to payer (together with rendezvous
node ID), and payer adds to that route the onion route from payer to
rendezvous point. This way, payer knows the rendezvous node ID, but not
the payee node ID. Payee knows the rendezvous node ID, but doesn't know
payer node ID either. Rendezvous node only knows that it's forwarding a
transaction, not from-where-to-where, or the purpose of the transaction.
📝 Original message:
Hi,
I am a bit concerned with the privacy implications of having either a
signed invoice + pre-image, or possibly a more powerful proof-of-payment
mechanism. In particular, I am concerned that it might provide
cryptographic evidence to the buyer that a certain seller performed the
transaction, and/or evidence to the seller that a certain buyer
performed the transaction.
In many cases, providing this evidence would be a feature rather than a
bug, allowing third-party dispute settlement (e.g. the legal system).
However, in my opinion, the Lightning network should also (or
especially) be suitable for more "sensitive" transactions. Even when
transactions are not illegal, I believe people still have a need to keep
some transaction information private. You don't want it to be possible
that your transaction history is stored on some company/person's server
for years, and then leaks out when that server gets hacked. Also, in my
opinion, we should *not* create a two-tier system of "sensitive" and
"nothing-to-hide" transactions: that would make the "sensitive"
transactions automatically suspicious, partially negating the whole
objective of being able to do sensitive transactions without
experiencing negative consequences.
To some degree, node IDs can act as pseudonyms, without evidence that
ties them to physical identities. However, I consider them to be
relatively poor pseudonyms: unlike, for instance, Bitcoin addresses,
creating a new node for every new transaction would have a serious
scalability impact, and defeat the whole purpose of Lightning. I think a
typical person would frequently perform transactions that are inherently
tied to their physical identity, e.g. receiving salary. This could give
the counterparty (the employer) a link between physical ID and node ID;
it might be forced to share this e.g. with authorities, further
increasing the odds of leak-out and/or abuse of data.
Maybe the solution is to have multiple nodes: one tied to your physical
ID, and one or more virtual identities? You could then transfer funds
between these nodes, and make sure no outsiders receive any
proof-of-payment info about these transfers. It sounds like an expensive
solution though, since you'd have to operate more channels to give each
node good connectivity.
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?
CJP
(*) Payee first finds a route from a rendezvous node to himself,
onion-encrypts that route, passes it to payer (together with rendezvous
node ID), and payer adds to that route the onion route from payer to
rendezvous point. This way, payer knows the rendezvous node ID, but not
the payee node ID. Payee knows the rendezvous node ID, but doesn't know
payer node ID either. Rendezvous node only knows that it's forwarding a
transaction, not from-where-to-where, or the purpose of the transaction.