Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z4rtt-0004YW-S9 for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 14:31:41 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.176 as permitted sender) client-ip=209.85.160.176; envelope-from=pieter.wuille@gmail.com; helo=mail-yk0-f176.google.com; Received: from mail-yk0-f176.google.com ([209.85.160.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z4rts-0006hi-3o for bitcoin-development@lists.sourceforge.net; Tue, 16 Jun 2015 14:31:41 +0000 Received: by ykar6 with SMTP id r6so14735162yka.2 for ; Tue, 16 Jun 2015 07:31:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.57.198 with SMTP id 189mr792746ykz.35.1434465094599; Tue, 16 Jun 2015 07:31:34 -0700 (PDT) Received: by 10.37.93.67 with HTTP; Tue, 16 Jun 2015 07:31:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jun 2015 16:31:34 +0200 Message-ID: From: Pieter Wuille To: Kalle Rosenbaum Content-Type: multipart/alternative; boundary=001a1139441e680b040518a36eb3 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Z4rts-0006hi-3o Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] BIP for Proof of Payment X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 14:31:41 -0000 --001a1139441e680b040518a36eb3 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum wrote: > 2015-06-15 12:00 GMT+02:00 Pieter Wuille : > 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 --001a1139441e680b040518a36eb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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. Ma= ybe
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 wa= nt to combine multiple payments in a single transaction.
=C2= =A0
> Also, if I understand correctly, there is no commitment to anything yo= u're
> trying to say about the sender? So once I obtain a proof-of-payment fr= om you
> about something you paid, I can go claim that it's mine?

I don't understand this. The pop includes a nonce randomly gener= ated
by the server. If you're very lucky, 1/(2^48) per try, you can reuse a<= br> pop.

=C2=A0
I owe yo= u 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,<= br> > 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 buye= r.

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=20 held the coins is the payer/buyer. That's what I said earlier; you'= re=20 implicitly creating an identity (the one who holds these keys) based on=20 the transaction. This seems fundamentally wrong to me, and not necessary. T= he receiver should not care who paid or how, he should care=20 what was payed for.
=C2=A0
The easiest solution to this IM= HO would be an extension to the payment protocol that gives you (or your wa= llet) a token in return for paying, and that knowledge of that token is use= d to gain access to the services you provide.

--
Piet= er

--001a1139441e680b040518a36eb3--