From corne at bitonic.nl  Fri Feb 23 12:08:40 2018
From: corne at bitonic.nl (=?UTF-8?Q?Corn=c3=a9_Plooy?=)
Date: Fri, 23 Feb 2018 13:08:40 +0100
Subject: [Lightning-dev] Privacy issues with proof of payment
In-Reply-To: <87606oinxy.fsf@rustcorp.com.au>
References: <08e75369-09e4-dfdd-d5f5-6c811ac17116@bitonic.nl>
	<87606oinxy.fsf@rustcorp.com.au>
Message-ID: <0757c550-fa18-445e-ba9d-2613eee9ad36@bitonic.nl>

Hi Rusty,
> The proof-of-payment here is a red herring, I think.  If we remove the
> destination awareness, the privacy issues seem greatly reduced.
>
Red herring = "something that misleads or distracts from a relevant or
important issue"[1]? Do you mean the proof-of-payment is irrelevant for
the privacy issue?

Trying to define proof-of-payment, in the typical use case of payment in
exchange of goods, I'd say that a proof of payment is a piece of data,
known to the payee, that allows the payee to prove that
??? "[<amount> was paid to <payee>, and in exchange] <payee> agreed to
transfer ownership of <goods> to <payer>".
For services, it would be
??? "[<amount> was paid to <payee>, and in exchange] <payee> agreed to
provide <services> to <payer>".

Requirements:
1. Proof-of-payment must be available to payer, who has the burden of
proof. By default, ownership of goods is not transferred, and there is
no obligation to provide services. Absence of proof should point to this
default. It is in the interest of payer to deviate from this default; if
he is capable of providing proof, he probably will.
2. The first part, "<amount> was paid to <payee>, and in exchange" is
optional: what I think really matters is the second part. Only in the
case that <payee> turns out to be incapable of delivering goods or
services, a dispute resolution party might be interested in the first
part, to find out what amount of monetary refund would be reasonable.
3. It is necessary that proof-of-payment proves agreement of <payee>:
otherwise, Eve could write "Alice agreed to transfer ownership of
<goods> to Eve" without consent of Alice.
4. It may not be necessary that proof-of-payment itself mentions
identity of <payee>, but it is necessary that <payee> becomes known to
the payer: "somebody agreed to transfer ownership of <goods> to <payer>"
does not indicate an obligation of any specific party. Without knowing
<payee>, it is impossible to verify 3.
5. It is necessary that proof-of-payment mentions the specific
obligation (e.g. delivery of goods/services); otherwise, it doesn't
prove anything useful.
6. It is necessary that proof-of-payment mentions <payer>: otherwise,
multiple potential payer parties could claim goods/services using copies
of a single proof-of-payment. Now that I think of it, it is way more
tricky than this, and I'm not sure that any mention of <payer> solves
anything. What you'd really want is that a single payment only results
in a single obligation of <payee>. However, IDs tend to be copyable,
just like proofs-of-payment. The best you can hope for is
difficult-to-copy IDs (like government-issued IDs) or very
inconvenient-to-copy (e.g. private keys of nodes that have significant
funds). How do you distinguish multiple identical transactions to the
same payer from the same payer making multiple false claims with the
same proof-of-payment? Include the payment hash to make it unique? I'm
not sure we're solving anything here.

The current invoice protocol[2] meets 1,2(optional part is
included),3(*),4(*),5(**), and can possibly meet 6(**), although there
is currently no defined protocol for payee to learn payer's identity.

There *are* some privacy issues with this kind of proof-of-payment:
3. requires payer to learn <payee>, and requires payee to provide
cryptographic proof of his consent to the transaction.
6. requires payee to learn <payer>. Because of its questionable
usefulness, I guess it's good there is no protocol defined for this.
However, 6. remains an open issue that does limit usefulness of
proofs-of-payment. Interestingly, while this knowledge provides
*evidence* for payer's involvement in the transaction, there is no
cryptographic *proof* of payer's involvement.

CJP

(*) the 'n' field is not required, but for routing and for verifying the
signature, payer currently still needs to know payee's node ID.
(**) optional: the 'd' and 'h' fields are free-format, and allow for this.

[1] https://en.wikipedia.org/wiki/Red_herring
[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md