Re: [Bitcoin-development] BIP for Proof of Payment

[Pieter Wuille <pieter.wuille@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:

> 2015-06-15 12:00 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com>:
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>

Not really. The problem is that you assume a transaction corresponds to a
single payment. This is true for simple wallet use cases, but not
compatible with CoinJoin, or with systems that for example would want to
combine multiple payments in a single transaction.


> > Also, if I understand correctly, there is no commitment to anything
> you're
> > trying to say about the sender? So once I obtain a proof-of-payment from
> you
> > about something you paid, I can go claim that it's mine?
>
> I don't understand this. The pop includes a nonce randomly generated
> by the server. If you're very lucky, 1/(2^48) per try, you can reuse a
> pop.
>
>
I owe you an apology here, for judging based on the summary you posted
rather than reading the actual text.

48 bits seems low to me, but it does indeed solve the problem. Why not 128
or 256 bits?

> Why does anyone care who paid? This is like walking into a coffeshop,
> > noticing I don't have money with me, let me friend pay for me, and then
> have
> > the shop insist that I can't drink it because I'm not the buyer.
>
> If you pay as you use the service (ie pay for coffee upfront), there's
> no need for PoP. Please see the Motivation section. But you are right
> that you must have the wallet(s) that paid at hand when you issue a
> PoP.
>
> >
> > Track payments, don't try to assign identities to payers.
>
> Please elaborate, I don't understand what you mean here.
>

I think that is a mistake. You should not assume that the wallet who held
the coins is the payer/buyer. That's what I said earlier; you're implicitly
creating an identity (the one who holds these keys) based on the
transaction. This seems fundamentally wrong to me, and not necessary. The
receiver should not care who paid or how, he should care what was payed for.

The easiest solution to this IMHO would be an extension to the payment
protocol that gives you (or your wallet) a token in return for paying, and
that knowledge of that token is used to gain access to the services you
provide.

-- 
Pieter

[-- Attachment #2: Type: text/html, Size: 3350 bytes --]