path: root/c4/0b6d9b7095756636aa7fb63026a9de7c3e78e3

Return-Path: <kalle@rosenbaum.se>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AEE3649B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 06:55:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
	[209.85.220.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0EE55EB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 24 Jul 2015 06:55:13 +0000 (UTC)
Received: by qkfc129 with SMTP id c129so9317628qkf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 Jul 2015 23:55:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type;
	bh=2dYQ376fBW1xinLErRTO9gwbC+9s23xDQ57rW+TZwFc=;
	b=CFJNRiYILn5Vq7L35Q85ee6+lkgD6v2usuLMIV/DT4KVg5yYq7NWq5YmDvAZMLmuFY
	TI6p9Gzs4loBRnYpWxyCjcjQcTqh3YCM4HFSjMsPTwhcAjKDMZ3x2VdcesChepw5fbL4
	9l4OOTd/un43xDEM/VZSmln957gf5mfj/N9fPYPBAKUnvlnpAT5z/u1tntygAE2dXDLm
	Trk7zPqKL4IwFywnkHTMSx6qHHOS7HJNLdxKlKsL+S1hTwjS89URyE3J8EvJgJsG4ILp
	iCKyGEE89kr3vcYOU4HHhc+UTtTcNioKnGtMJxpwieACGeWIpqtf9KnEkWlwrFjvUxzv
	nTXw==
X-Gm-Message-State: ALoCoQnXjXmwNkNmUo44MoeYV051EXiEQA/bAWy8EHlOjcytfydPlPAK9rBiImO5kUtwK6iAkB73
MIME-Version: 1.0
X-Received: by 10.55.17.195 with SMTP id 64mr18407467qkr.43.1437720912267;
	Thu, 23 Jul 2015 23:55:12 -0700 (PDT)
Received: by 10.96.127.227 with HTTP; Thu, 23 Jul 2015 23:55:12 -0700 (PDT)
Received: by 10.96.127.227 with HTTP; Thu, 23 Jul 2015 23:55:12 -0700 (PDT)
In-Reply-To: <CAPswA9w8QaWV72UuGnitWWeDTr5MPKvzwrD5udmq_FQke-NGAQ@mail.gmail.com>
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
	<CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
	<CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
	<CALJP9GCBJiofY7k2RJ460CuLuWQunHcx7EcLi1-d07v76Y-E2g@mail.gmail.com>
	<CAPswA9wqdbU0z8ydBt+9M0iQX0VSi1ce=dg3fR2_2bx3-vEqzA@mail.gmail.com>
	<CAPswA9z_xKY6v9=Ejh=01mZN0QCVo1e0RY1FTzXzS39i3tjgAw@mail.gmail.com>
	<CAPswA9xk5QYAXxQ6ES3cnNPeB1FTiiSJgLahLEkSk4CLpoM_QQ@mail.gmail.com>
	<CAPg+sBiWykR6RaHhbyYQbL=A5t1TmHgEmS_sC7jj9d3SUTMO9g@mail.gmail.com>
	<CAPswA9zycU0pwZKaHU9J3Tvg=ovLJ8TZ9OH6ebTPONaRaiOE8g@mail.gmail.com>
	<CAPg+sBhuth22+vAHyS2iwpze8X=-b2wJQ5s1z2FhZ1jsLXobgQ@mail.gmail.com>
	<CAPswA9yB3wfV1auXR=ggXjh+f1C3Qpkv8qP1miQwkc8R2_aBLg@mail.gmail.com>
	<CAPg+sBjp-BmSXhanOuKE0DN1wdfVwCtFwiAbPse1GLxy3+L3nA@mail.gmail.com>
	<CAPswA9zzKvh6G+NqzTmhrNXMSWOPtZ2DGW2t_2Jrisy8x9m2qw@mail.gmail.com>
	<CAPg+sBhZCayaxNg_thO=nzxvuo-xZ-ZeZMXEVWb6Mw2POreOZQ@mail.gmail.com>
	<CAPswA9yFUAqFyNBFBnnwpT=B9RcdNssdjz-_KWbX5GuLM5Uyxw@mail.gmail.com>
	<CAPg+sBigK7K2YVnhcU5Ysf0d0Gbp+GaNdGoKZCco5zvYLKDxFw@mail.gmail.com>
	<CAPswA9wLDpf0Q3aL=a+uaqkFecPgC4ASj73XVfj=MOrof-yh1g@mail.gmail.com>
	<CAPswA9z5fo5Vw_cSoUu1qtgU4kKf+W3FxREPJ5UpvvJUSi+doA@mail.gmail.com>
	<CAPswA9w8QaWV72UuGnitWWeDTr5MPKvzwrD5udmq_FQke-NGAQ@mail.gmail.com>
Date: Fri, 24 Jul 2015 08:55:12 +0200
Message-ID: <CAPswA9ydvva=BqtqVAc0deDE+do0vm8CawOLX5d5D-BV59vtyA@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1147406043218a051b997c11
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] [Bitcoin-development] BIP for Proof of Payment
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2015 06:55:14 -0000

--001a1147406043218a051b997c11
Content-Type: text/plain; charset=UTF-8

These BIPs have been assigned 120 and 121:

120: Proof of Payment
121: Proof of Payment URI scheme

Regards,
Kalle
Den 24 jul 2015 08:27 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:

> These BIPs have been assigned 120 and 121:
>
> 120: Proof of Payment
> 121: Proof of Payment URI scheme
>
> Regards,
> Kalle
> Den 21 jun 2015 16:39 skrev "Kalle Rosenbaum" <kalle@rosenbaum.se>:
>
>> Hi Greg!
>>
>> After a lot of constructive discussion, feedback and updating, I'm
>> requesting that you please assign these proposals BIP numbers. It's both
>> the "Proof of Payment" proposal and the "Proof of Payment URI scheme"
>> proposal that I'm referring to.
>>
>> The wikimedia source is available here:
>> https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP and
>> https://github.com/kallerosenbaum/poppoc/wiki/btcpop-scheme-BIP.
>>
>> Is this what you need in order to proceed or is there something else you
>> need from me?
>>
>> Best regards,
>> /Kalle
>>
>> 2015-06-17 11:51 GMT+02:00 Kalle Rosenbaum <kalle@rosenbaum.se>:
>>
>>> 2015-06-16 21:48 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com>:
>>> > I don't see why existing software could create a 40-byte OP_RETURN but
>>> not
>>> > larger? The limitation comes from a relay policy in full nodes, not a
>>> > limitation is wallet software... and PoPs are not relayed on the
>>> network.
>>>
>>> You are probably right here. The thing is that I don't know how *all*
>>> wallet signing and validating software is written, so I figure it's
>>> better to stick to a "valid" output. Since I don't *need* more data
>>> than 40 bytes, why bother. There's another constraint to this as well:
>>> The other BIP proposal, "Proof of Payment URI scheme", includes a
>>> nonce parameter in the URI. If the nonce is very long, the QR code
>>> will be unnecessarily big. The server should try to detect a brute
>>> force of the 48 bit nonce, or at least delay the pop requests by some
>>> 100 ms or so.
>>>
>>> Do you think this is an actual problem, and why? Is your suggestion to
>>> use a bigger nonce, given the above?
>>>
>>> >
>>> > Regarding sharing, I think you're talking about a different use case.
>>> Say
>>> > you want to pay for 1-week valid entrance to some venue. I thought the
>>> > purpose of the PoP was to be sure that only the person who paid for
>>> it, and
>>> > not anyone else can use it during that week.
>>> >
>>>
>>> That's right. That's one use case. You pay for the 1-week entrance and
>>> then you use your wallet to sign PoPs when you enter the venue.
>>>
>>> > My argument against that is that the original payer can also hand the
>>> > private keys in his wallet to someone else, who would then become able
>>> to
>>> > create PoPs for the service. He does not lose anything by this,
>>> assuming the
>>> > address is not reused.
>>> >
>>>
>>> Yes, that is possible. It's about the same as giving out a
>>> username/password for a service that you have paid for. In the case of
>>> a concert ticket, it's simple. Just allow one entrance per payment.
>>> But in the example you gave, it's a bit more complicated. You could
>>> for example give all guests a bracelet upon first entry or upon first
>>> exit. Or you can put a stamp on people leaving the venue, and demand
>>> that all re-entries show the stamp, possibly along with a new PoP.
>>> Pretty much as is done already. Different use cases will need
>>> different protection. In this example, the value added by PoP is that
>>> the venue does not have to distribute tickets in advance. This in turn
>>> allows for better privacy for the customer, who don't have to give out
>>> personal information such as an email-address.
>>>
>>> > So, using a token does not change anything, except it can be provided
>>> to the
>>> > payer - instead of relying on creating an implicit identity based on
>>> who
>>> > seems to have held particular private keys in the past.
>>> >
>>>
>>> Yes, that's a difference, but it comes at the cost of security. The
>>> stolen token can be used over and over. In the case of PoP it's only
>>> usable once, and it's only created when it's actually needed,
>>> minimizing the window of opportunity for the thief.
>>>
>>> Regards,
>>> Kalle
>>>
>>> > On Jun 16, 2015 9:41 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se> wrote:
>>> >>
>>> >> 2015-06-16 21:25 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com>:
>>> >> > You can't avoid sharing the token, and you can't avoid sharing the
>>> >> > private
>>> >> > keys used for signing either. If they are single use, you don't lose
>>> >> > anything by sharing them.
>>> >>
>>> >> Forwarding the PoP request would be a way to avoid sharing keys, as
>>> >> suggested above.
>>> >>
>>> >> >
>>> >> > Also you are not creating a real transaction. Why does the OP_RETURN
>>> >> > limitation matter?
>>> >>
>>> >> This was discussed in the beginning of this thread: "The idea is to
>>> >> simplify implementation. Existing software can be used as is to sign
>>> >> and validate PoPs"
>>> >>
>>> >> Regards,
>>> >> Kalle
>>> >>
>>> >> >
>>> >> > On Jun 16, 2015 9:22 PM, "Kalle Rosenbaum" <kalle@rosenbaum.se>
>>> wrote:
>>> >> >>
>>> >> >> Thank you for your comments Pieter! Please find my answers below.
>>> >> >>
>>> >> >> 2015-06-16 16:31 GMT+02:00 Pieter Wuille <pieter.wuille@gmail.com
>>> >:
>>> >> >> > 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.
>>> >> >> >
>>> >> >>
>>> >> >> Yes, you are right. It's not compatible with CoinJoin and the
>>> likes.
>>> >> >>
>>> >> >> >
>>> >> >> > 48 bits seems low to me, but it does indeed solve the problem.
>>> Why
>>> >> >> > not
>>> >> >> > 128
>>> >> >> > or 256 bits?
>>> >> >>
>>> >> >> The nonce is limited because of the OP_RETURN output being limited
>>> to
>>> >> >> 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes nonce.
>>> >> >>
>>> >> >> >
>>> >> >> >> > 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.
>>> >> >>
>>> >> >> You are saying that it's a problem that the wallet used to pay,
>>> must
>>> >> >> also be used to issue the PoP? That may very well be a problem in
>>> some
>>> >> >> cases. People using PoP should of course be aware of it's
>>> limitations
>>> >> >> and act accordingly, i.e. don't pay for concert tickets for a
>>> friend
>>> >> >> and expect your friend to be able to enter the arena with her
>>> wallet.
>>> >> >> As Tom Harding noted, it is possible to transfer keys to your
>>> friend's
>>> >> >> wallet, but that might not be desirable if those keys are also used
>>> >> >> for other payments. Also that would weaken the security of an HD
>>> >> >> wallet, since a chain code along with a private key would reveal
>>> all
>>> >> >> keys in that tree. Another solution is that your friend forwards
>>> the
>>> >> >> PoP request to your wallet, through twitter or SMS, and you send
>>> the
>>> >> >> PoP for her. Maybe that forwarding mechanism can be built into
>>> wallets
>>> >> >> and automated so that the wallet automatically suggests to sign the
>>> >> >> PoP for your friend. This is probably something to investigate
>>> >> >> further, but not within the scope of this BIP.
>>> >> >>
>>> >> >> Of course the simplest solution would be to send money to your
>>> friend
>>> >> >> first so that she can pay for the ticket from her own wallet, but
>>> >> >> that's not always feasible.
>>> >> >>
>>> >> >> >
>>> >> >> > 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.
>>> >> >> >
>>> >> >>
>>> >> >> That token would then be reusable. Someone stealing it would be
>>> able
>>> >> >> to use it as much as she wants. That is what I want to avoid with
>>> PoP.
>>> >> >> The BIP proposal briefly mentions something like this in the
>>> >> >> rationale. I also had a discussion about this with Mike Hearn on
>>> this
>>> >> >> list on Mars 13 that I think covers most pros and cons of the
>>> >> >> different approaches.
>>> >> >>
>>> >> >> While your suggestion does indeed separate the transaction from the
>>> >> >> proof of payment, it also assumes that the token is held in the
>>> wallet
>>> >> >> that pays. Otherwise you would need to keep it in another safe
>>> place,
>>> >> >> remember it's reusable. Where would that be? How would you transfer
>>> >> >> that token to your friend?
>>> >> >>
>>> >> >> Thank you again for your comments. I appreciate it.
>>> >> >>
>>> >> >> Best regards,
>>> >> >> Kalle
>>> >> >>
>>> >> >> > --
>>> >> >> > Pieter
>>> >> >> >
>>>
>>
>>

--001a1147406043218a051b997c11
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">These BIPs have been assigned 120 and 121:</p>
<p dir=3D"ltr">120: Proof of Payment=C2=A0<br>
121: Proof of Payment URI scheme</p>
<p dir=3D"ltr">Regards,=C2=A0<br>
Kalle</p>
<div class=3D"gmail_quote">Den 24 jul 2015 08:27 skrev &quot;Kalle Rosenbau=
m&quot; &lt;<a href=3D"mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt=
;:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Th=
ese BIPs have been assigned 120 and 121:</p>
<p dir=3D"ltr">120: Proof of Payment <br>
121: Proof of Payment URI scheme</p>
<p dir=3D"ltr">Regards, <br>
Kalle </p>
<div class=3D"gmail_quote">Den 21 jun 2015 16:39 skrev &quot;Kalle Rosenbau=
m&quot; &lt;<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@r=
osenbaum.se</a>&gt;:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>Hi Greg!<br><br>After a lot of constructive discussi=
on, feedback and updating, I&#39;m requesting that you please assign these =
proposals BIP numbers. It&#39;s both the &quot;Proof of Payment&quot; propo=
sal and the &quot;Proof of Payment URI scheme&quot; proposal that I&#39;m r=
eferring to.<br><br>The wikimedia source is available here: <a href=3D"http=
s://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP" target=3D"_=
blank">https://github.com/kallerosenbaum/poppoc/wiki/Proof-of-Payment-BIP</=
a> and <a href=3D"https://github.com/kallerosenbaum/poppoc/wiki/btcpop-sche=
me-BIP" target=3D"_blank">https://github.com/kallerosenbaum/poppoc/wiki/btc=
pop-scheme-BIP</a>.<br><br></div>Is this what you need in order to proceed =
or is there something else you need from me?<br><div><br>Best regards,<br>/=
Kalle<br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2015-06-17 11:51 GMT+02:00 Kalle Rosenbaum <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&gt=
;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><span>2015-06-16 21:48 GMT+02:0=
0 Pieter Wuille &lt;<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_b=
lank">pieter.wuille@gmail.com</a>&gt;:<br>
&gt; I don&#39;t see why existing software could create a 40-byte OP_RETURN=
 but not<br>
&gt; larger? The limitation comes from a relay policy in full nodes, not a<=
br>
&gt; limitation is wallet software... and PoPs are not relayed on the netwo=
rk.<br>
<br>
</span>You are probably right here. The thing is that I don&#39;t know how =
*all*<br>
wallet signing and validating software is written, so I figure it&#39;s<br>
better to stick to a &quot;valid&quot; output. Since I don&#39;t *need* mor=
e data<br>
than 40 bytes, why bother. There&#39;s another constraint to this as well:<=
br>
The other BIP proposal, &quot;Proof of Payment URI scheme&quot;, includes a=
<br>
nonce parameter in the URI. If the nonce is very long, the QR code<br>
will be unnecessarily big. The server should try to detect a brute<br>
force of the 48 bit nonce, or at least delay the pop requests by some<br>
100 ms or so.<br>
<br>
Do you think this is an actual problem, and why? Is your suggestion to<br>
use a bigger nonce, given the above?<br>
<span><br>
&gt;<br>
&gt; Regarding sharing, I think you&#39;re talking about a different use ca=
se. Say<br>
&gt; you want to pay for 1-week valid entrance to some venue. I thought the=
<br>
&gt; purpose of the PoP was to be sure that only the person who paid for it=
, and<br>
&gt; not anyone else can use it during that week.<br>
&gt;<br>
<br>
</span>That&#39;s right. That&#39;s one use case. You pay for the 1-week en=
trance and<br>
then you use your wallet to sign PoPs when you enter the venue.<br>
<span><br>
&gt; My argument against that is that the original payer can also hand the<=
br>
&gt; private keys in his wallet to someone else, who would then become able=
 to<br>
&gt; create PoPs for the service. He does not lose anything by this, assumi=
ng the<br>
&gt; address is not reused.<br>
&gt;<br>
<br>
</span>Yes, that is possible. It&#39;s about the same as giving out a<br>
username/password for a service that you have paid for. In the case of<br>
a concert ticket, it&#39;s simple. Just allow one entrance per payment.<br>
But in the example you gave, it&#39;s a bit more complicated. You could<br>
for example give all guests a bracelet upon first entry or upon first<br>
exit. Or you can put a stamp on people leaving the venue, and demand<br>
that all re-entries show the stamp, possibly along with a new PoP.<br>
Pretty much as is done already. Different use cases will need<br>
different protection. In this example, the value added by PoP is that<br>
the venue does not have to distribute tickets in advance. This in turn<br>
allows for better privacy for the customer, who don&#39;t have to give out<=
br>
personal information such as an email-address.<br>
<span><br>
&gt; So, using a token does not change anything, except it can be provided =
to the<br>
&gt; payer - instead of relying on creating an implicit identity based on w=
ho<br>
&gt; seems to have held particular private keys in the past.<br>
&gt;<br>
<br>
</span>Yes, that&#39;s a difference, but it comes at the cost of security. =
The<br>
stolen token can be used over and over. In the case of PoP it&#39;s only<br=
>
usable once, and it&#39;s only created when it&#39;s actually needed,<br>
minimizing the window of opportunity for the thief.<br>
<div><div><br>
Regards,<br>
Kalle<br>
<br>
&gt; On Jun 16, 2015 9:41 PM, &quot;Kalle Rosenbaum&quot; &lt;<a href=3D"ma=
ilto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&gt; wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; 2015-06-16 21:25 GMT+02:00 Pieter Wuille &lt;<a href=3D"mailto:pie=
ter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>&gt;:<br=
>
&gt;&gt; &gt; You can&#39;t avoid sharing the token, and you can&#39;t avoi=
d sharing the<br>
&gt;&gt; &gt; private<br>
&gt;&gt; &gt; keys used for signing either. If they are single use, you don=
&#39;t lose<br>
&gt;&gt; &gt; anything by sharing them.<br>
&gt;&gt;<br>
&gt;&gt; Forwarding the PoP request would be a way to avoid sharing keys, a=
s<br>
&gt;&gt; suggested above.<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Also you are not creating a real transaction. Why does the OP=
_RETURN<br>
&gt;&gt; &gt; limitation matter?<br>
&gt;&gt;<br>
&gt;&gt; This was discussed in the beginning of this thread: &quot;The idea=
 is to<br>
&gt;&gt; simplify implementation. Existing software can be used as is to si=
gn<br>
&gt;&gt; and validate PoPs&quot;<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt; Kalle<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Jun 16, 2015 9:22 PM, &quot;Kalle Rosenbaum&quot; &lt;<a h=
ref=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se</a>&=
gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Thank you for your comments Pieter! Please find my answer=
s below.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; 2015-06-16 16:31 GMT+02:00 Pieter Wuille &lt;<a href=3D"m=
ailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a=
>&gt;:<br>
&gt;&gt; &gt;&gt; &gt; On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum &lt=
;<a href=3D"mailto:kalle@rosenbaum.se" target=3D"_blank">kalle@rosenbaum.se=
</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; 2015-06-15 12:00 GMT+02:00 Pieter Wuille &lt;<a =
href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gma=
il.com</a>&gt;:<br>
&gt;&gt; &gt;&gt; &gt;&gt; I&#39;m not sure if we will be able to support P=
oP with CoinJoin. Maybe<br>
&gt;&gt; &gt;&gt; &gt;&gt; someone with more insight into CoinJoin have som=
e input?<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Not really. The problem is that you assume a transac=
tion corresponds<br>
&gt;&gt; &gt;&gt; &gt; to<br>
&gt;&gt; &gt;&gt; &gt; a<br>
&gt;&gt; &gt;&gt; &gt; single payment. This is true for simple wallet use c=
ases, but not<br>
&gt;&gt; &gt;&gt; &gt; compatible<br>
&gt;&gt; &gt;&gt; &gt; with CoinJoin, or with systems that for example woul=
d want to combine<br>
&gt;&gt; &gt;&gt; &gt; multiple payments in a single transaction.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Yes, you are right. It&#39;s not compatible with CoinJoin=
 and the likes.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; 48 bits seems low to me, but it does indeed solve th=
e problem. Why<br>
&gt;&gt; &gt;&gt; &gt; not<br>
&gt;&gt; &gt;&gt; &gt; 128<br>
&gt;&gt; &gt;&gt; &gt; or 256 bits?<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; The nonce is limited because of the OP_RETURN output bein=
g limited to<br>
&gt;&gt; &gt;&gt; 40 bytes of data: 2 bytes version, 32 bytes txid, 6 bytes=
 nonce.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; Why does anyone care who paid? This is like=
 walking into a<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; coffeshop,<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; noticing I don&#39;t have money with me, le=
t me friend pay for me, and<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; then<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; have<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; the shop insist that I can&#39;t drink it b=
ecause I&#39;m not the buyer.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; If you pay as you use the service (ie pay for co=
ffee upfront),<br>
&gt;&gt; &gt;&gt; &gt;&gt; there&#39;s<br>
&gt;&gt; &gt;&gt; &gt;&gt; no need for PoP. Please see the Motivation secti=
on. But you are<br>
&gt;&gt; &gt;&gt; &gt;&gt; right<br>
&gt;&gt; &gt;&gt; &gt;&gt; that you must have the wallet(s) that paid at ha=
nd when you issue a<br>
&gt;&gt; &gt;&gt; &gt;&gt; PoP.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; Track payments, don&#39;t try to assign ide=
ntities to payers.<br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Please elaborate, I don&#39;t understand what yo=
u mean here.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; I think that is a mistake. You should not assume tha=
t the wallet who<br>
&gt;&gt; &gt;&gt; &gt; held<br>
&gt;&gt; &gt;&gt; &gt; the coins is the payer/buyer. That&#39;s what I said=
 earlier; you&#39;re<br>
&gt;&gt; &gt;&gt; &gt; implicitly<br>
&gt;&gt; &gt;&gt; &gt; creating an identity (the one who holds these keys) =
based on the<br>
&gt;&gt; &gt;&gt; &gt; transaction. This seems fundamentally wrong to me, a=
nd not necessary.<br>
&gt;&gt; &gt;&gt; &gt; The<br>
&gt;&gt; &gt;&gt; &gt; receiver should not care who paid or how, he should =
care what was<br>
&gt;&gt; &gt;&gt; &gt; payed<br>
&gt;&gt; &gt;&gt; &gt; for.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; You are saying that it&#39;s a problem that the wallet us=
ed to pay, must<br>
&gt;&gt; &gt;&gt; also be used to issue the PoP? That may very well be a pr=
oblem in some<br>
&gt;&gt; &gt;&gt; cases. People using PoP should of course be aware of it&#=
39;s limitations<br>
&gt;&gt; &gt;&gt; and act accordingly, i.e. don&#39;t pay for concert ticke=
ts for a friend<br>
&gt;&gt; &gt;&gt; and expect your friend to be able to enter the arena with=
 her wallet.<br>
&gt;&gt; &gt;&gt; As Tom Harding noted, it is possible to transfer keys to =
your friend&#39;s<br>
&gt;&gt; &gt;&gt; wallet, but that might not be desirable if those keys are=
 also used<br>
&gt;&gt; &gt;&gt; for other payments. Also that would weaken the security o=
f an HD<br>
&gt;&gt; &gt;&gt; wallet, since a chain code along with a private key would=
 reveal all<br>
&gt;&gt; &gt;&gt; keys in that tree. Another solution is that your friend f=
orwards the<br>
&gt;&gt; &gt;&gt; PoP request to your wallet, through twitter or SMS, and y=
ou send the<br>
&gt;&gt; &gt;&gt; PoP for her. Maybe that forwarding mechanism can be built=
 into wallets<br>
&gt;&gt; &gt;&gt; and automated so that the wallet automatically suggests t=
o sign the<br>
&gt;&gt; &gt;&gt; PoP for your friend. This is probably something to invest=
igate<br>
&gt;&gt; &gt;&gt; further, but not within the scope of this BIP.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Of course the simplest solution would be to send money to=
 your friend<br>
&gt;&gt; &gt;&gt; first so that she can pay for the ticket from her own wal=
let, but<br>
&gt;&gt; &gt;&gt; that&#39;s not always feasible.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; The easiest solution to this IMHO would be an extens=
ion to the<br>
&gt;&gt; &gt;&gt; &gt; payment<br>
&gt;&gt; &gt;&gt; &gt; protocol that gives you (or your wallet) a token in =
return for<br>
&gt;&gt; &gt;&gt; &gt; paying,<br>
&gt;&gt; &gt;&gt; &gt; and<br>
&gt;&gt; &gt;&gt; &gt; that knowledge of that token is used to gain access =
to the services<br>
&gt;&gt; &gt;&gt; &gt; you<br>
&gt;&gt; &gt;&gt; &gt; provide.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; That token would then be reusable. Someone stealing it wo=
uld be able<br>
&gt;&gt; &gt;&gt; to use it as much as she wants. That is what I want to av=
oid with PoP.<br>
&gt;&gt; &gt;&gt; The BIP proposal briefly mentions something like this in =
the<br>
&gt;&gt; &gt;&gt; rationale. I also had a discussion about this with Mike H=
earn on this<br>
&gt;&gt; &gt;&gt; list on Mars 13 that I think covers most pros and cons of=
 the<br>
&gt;&gt; &gt;&gt; different approaches.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; While your suggestion does indeed separate the transactio=
n from the<br>
&gt;&gt; &gt;&gt; proof of payment, it also assumes that the token is held =
in the wallet<br>
&gt;&gt; &gt;&gt; that pays. Otherwise you would need to keep it in another=
 safe place,<br>
&gt;&gt; &gt;&gt; remember it&#39;s reusable. Where would that be? How woul=
d you transfer<br>
&gt;&gt; &gt;&gt; that token to your friend?<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Thank you again for your comments. I appreciate it.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Best regards,<br>
&gt;&gt; &gt;&gt; Kalle<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt; --<br>
&gt;&gt; &gt;&gt; &gt; Pieter<br>
&gt;&gt; &gt;&gt; &gt;<br>
</div></div></blockquote></div><br></div>
</blockquote></div>
</blockquote></div>

--001a1147406043218a051b997c11--