> I am a bit concerned with the privacy implications of having either a
signed
> invoice
<snip>
> 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.

It's 100% opt-in. If either party doesn't wish to allow any sort of
proof-of-payment, or service, or whatever, then they don't need to. In this
case the sender would just obtain the payment parameters (skipping BOLT11 or
w/e other follow ups in the feature), and make a "raw" payment. Without
interaction from the sender, there are various classes of spontaneous
payments available as well.

>From the PoV of the network (or participants in the payment path), it's
indistinguishable. Only the end points need to decide if their use case is
one that both opt into for a proof of payment scheme.

-- Laolu


On Fri, Feb 23, 2018 at 4:08 AM Corné Plooy via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> 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
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to