path: root/65/060356262d0da918c0d4a280ddf91e5f5680b8

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephen@bitpay.com>) id 1TllsB-0008G2-Sh
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 19:33:39 +0000
Received: from mail-la0-f41.google.com ([209.85.215.41])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Tlls9-0001En-NC
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 19:33:39 +0000
Received: by mail-la0-f41.google.com with SMTP id m15so3668619lah.28
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 20 Dec 2012 11:33:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=x-received:mime-version:x-originating-ip:in-reply-to:references
	:from:date:message-id:subject:to:cc:content-type:x-gm-message-state;
	bh=8T2OEuc5M4xrpvs/PuQsD4U0mtgGnAU7njIhGB1ba6Y=;
	b=Qvlil7UGgygES/gI9A9CwkWwwKYHKOLy48Ox3si5xloYb8+D9R57Y7kD7l+A4V41lo
	Ec6uRY1zyWOfDHoKA15CEJ/f1xvbfmImF1f2usYl4JQh1/4qpd3r1kMx8uA9FZHVR9wM
	2VvAa57eqHhlKv/ba/MUF6XGLShOAtEmyQZ0hvFrLwoMaEZyGQpl1eCtUln27hLOvnwc
	ElS1Bu+yrazNuz670apnJV2ElxJQ20C0mkpZOJo4nOAaoTmV7qIz4hMS9s1vcfB+pLO/
	PCxgBrhNqFBQQF4mqb7quK/hyHx8Srr14O57WEsdu+ET4pSEqA8uLFO8MimmzqvvV97K
	/XOQ==
X-Received: by 10.152.132.137 with SMTP id ou9mr10046973lab.7.1356032010721;
	Thu, 20 Dec 2012 11:33:30 -0800 (PST)
Received: from mail-la0-f42.google.com (mail-la0-f42.google.com
	[209.85.215.42])
	by mx.google.com with ESMTPS id ns7sm2375032lab.5.2012.12.20.11.33.28
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Dec 2012 11:33:29 -0800 (PST)
Received: by mail-la0-f42.google.com with SMTP id s15so3686291lag.15
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 20 Dec 2012 11:33:28 -0800 (PST)
Received: by 10.152.106.163 with SMTP id gv3mr9808169lab.55.1356032007998;
	Thu, 20 Dec 2012 11:33:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.17.231 with HTTP; Thu, 20 Dec 2012 11:32:46 -0800 (PST)
X-Originating-IP: [71.204.90.78]
In-Reply-To: <CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
	<20121128233619.GA6368@giles.gnomon.org.uk>
	<CABsx9T09FYf2RTaMpmujt3qwTFc2JgnREH_7Hyk2mnCgb3CvAw@mail.gmail.com>
	<20121129170713.GD6368@giles.gnomon.org.uk>
	<CANEZrP233CytLs3PWBQ1TyuBTMv4sLGJkEMeGWYq5xRi+iLKew@mail.gmail.com>
	<20121129185330.GE6368@giles.gnomon.org.uk>
	<CABsx9T35qD_xJEVw002eAhJ1kr6x5aMU7RpD+U84XEOZXmXcYw@mail.gmail.com>
	<CAErK2ChjAm-Zf11YXuBQeTQvahOEJNGiPSZaD-CQ=OU9K6HtZA@mail.gmail.com>
	<CAKaEYh+OUD4kfxwSNQBCJXmj6Kwb8jy9Au=Mfrqr2sKv7SuHpg@mail.gmail.com>
	<CA+8xBpeya92UR60_ba+xYycjONOOvYUcW4Fe+SNdWwpg7aWEHw@mail.gmail.com>
	<CAKaEYh+jJn0dPsGn_RnOy3NmWMc0F12Dffx2jYBUA=z+W45fWA@mail.gmail.com>
	<CANEZrP1v9E1S1VA2p-pCzrobp8ueWZTf0r0stZ3JyJ==u_Zgxg@mail.gmail.com>
	<CAKaEYhLbeBfJeLtBJTkX6S-MbqdWuQrcpNKpY2Czhhk3T6frmA@mail.gmail.com>
	<CABsx9T1QjDfg-hKorJCk8Sdhf0fw9qQjV8R8EPNvU0m0nQF3tw@mail.gmail.com>
	<CADb9v0K9xD+ndB-dJDkmPOuo1omrtMk3WTo238OjVcWoQ-CmXA@mail.gmail.com>
	<CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com>
From: Stephen Pair <stephen@bitpay.com>
Date: Thu, 20 Dec 2012 14:32:46 -0500
Message-ID: <CADb9v0Lc3HDpLO_ZdibPcxyrggACVfG+482oj72=986pfSc4mA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04083aad240c5a04d14dcea7
X-Gm-Message-State: ALoCoQmi8NjbHev7YPLvG6EPirxNQVya94+LX9MNG2s0bWFEnG33DfuV5T0oHiXMze1OsHlS1NVx
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Tlls9-0001En-NC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
	Invoices/Payments/Receipts
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2012 19:33:40 -0000

--f46d04083aad240c5a04d14dcea7
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 20, 2012 at 12:43 PM, Mike Hearn <mike@plan99.net> wrote:

> > you may find yourself in a situation needing to parse a protobuf
> > message in a web browser
> Nothing stops you converting them into whatever form you want on the
> server side. If you don't care about the signature checking then it's
> no problem to use a server. If you do then you'd need to ship all the
> code for verifying signatures that to the client anyway, at which
> point a small protobuf parser is hardly a deal killer.


No, it's not a killer...just a hassle.  JSON is convenient and ubiquitous
and there is something to be said for that (and I wanted to point out that
the JOSE objection was invalid).  Protobufs are nice and efficient, but who
cares.  You're talking about direct communications rather than something
that will be bounced around every node in the mesh network.  I don't really
care much either way, it's not worth debating.  I'm just thankful no one is
arguing for XML or IIOP.  :)

> ...like what about the casual user that wants to create a payment request
> to
> > send to their friend over email
>
> They can send an unsigned payment request. Note that if you mail it as
> an attachment from a competent, up to date email provider then the
> attachment isn't really unsigned. The whole thing is covered by the
> emails DKIM signature which is applied transparently by the ESP. If
> the signature fails to verify then the mail client can show that or
> treat the mail differently (as Gmail does). This is easy to use for
> the end user - they don't have to think about cryptography or PKI. As
> long as their email account is secure then they can send signed mails
> asserting to their identity.
>

This leaves too much to chance for my taste.  Forget email, what about
jabber, ICQ, skype, IRC?  Email is just one communications medium, there
are many others for which there would be no assurance that the payment
request hasn't been tampered with.  You could at a minimum allow a person
to create a normal ECC key, but have it used as an identity in
communications rather than a payment address.  You store it in a separate
file in ~/.bitcoin/id  ...you don't have to solve the whole set of PKI
problems, people could exchange identities using any secure channel they
are comfortable with (email + phone verification of a short hash id would
be sufficient).  In another scenario, an id could be made available over
https, using the normal SSL certificate and CA infrastructure to verify
authenticity.  This way all messages could be signed and/or encrypted
without the user having to go out of their way to use external tools or
infrastructure that is often not very user friendly.  You also need
encryption for the "cheque" feature...asking people to use GPG would be too
much of a burden (and email DKIM doesn't offer encryption).

>>> wandering off topic >>>
Indeed, "cheques" could become the dominant method of person to person
payments...first, you would obtain someone's id, which you might already
have on file (rather than obtaining a bitcoin address), then you would
generate a "cheque" for the amount desired and send it to them...the
recipient then has full control over what address they want to sweep the
funds to as well as whether they'd like to include a miner fee to speed the
confirmation along. Despite the fact that you may send many payments to the
same identity, the only thing showing up on the p2p network and the block
chain is the one time use address for the cheque and the recipient's wallet
address.  This means the recipient has much more control over the address
policy used (compared with simply giving out a bitcoin address that may be
reused).
<<<

> Refund addresses...this is not going to be as useful as people might
> > think...most refunds that bitpay needs to process happen days or even
> months
> > after the initial purchase
>
> Useful feedback, thanks. Still, there may be other types of merchants
> for whom it's useful, and many users won't change their wallet. It
> certainly simplifies things if you can present the refund address and
> give a one-click option to use it. If the user wants to use a
> different address, then they can go onto the slow/complicated path.
>
> This current spec deliberately punts on the topic of identifying end
> users. It's a difficult problem.
>

I know, but as I was responding, I began to realize this is a mistake.
 It's worthwhile to tackle that problem first...if done right, it would pay
huge dividends.  Also, identity is one thing, an elaborate trust based
identity verification system (like CA's) is a whole other thing.  I think
the former is pretty simple actually...and it's all that's really needed
for the time being (as I alluded, a bitcoin identity could be communicated
or verified using the existing X.509/CA infrastructure if desired...you
could also use the PGP infrastructure).


> > I like the use of merchant_data...this means that you no longer will
> need a
> > unique bitcoin address for every invoice.
>
> It's still a good idea to use one for privacy reasons.


Actually, I was speaking more in terms of relying on the address to match
up a transaction to an invoice.  The merchant_data field frees you from
having to do that.


> The merchant
> data is there so you can stuff whatever state you want into it. So
> it's like cookies. You don't have to keep state on the server side.
> Just encrypt/sign it, put it in the invoice, and when you get a
> payment message back there's no need to do database lookups or
> anything, you can just do some crypto and know who is submitting it.
>

Yeah, that's neat...I hadn't thought of that possibility.


>  > Generally speaking, I'm not a fan of embedding things like that
>
> What's wrong with it? Isn't your proposal more complex? I don't see
> why it's better than just embedding it.
>

It's not a big deal, I just think a referential model is more general than
embedding objects within each other.


>  > The Receipt should be signed...it could be used as proof of payment by
> > wallets.
>
> There's no Receipt message, a SignedPaymentRequest + transactions that
> pay to the requested outputs are together the proof of payment.
>

Ah, I see it was renamed PaymentACK...the point of signing a PaymentACK is
that while you could prove that you paid according to a PaymentRequest, a
signed PaymentACK is proof that the recipient acknowledged you have made
that payment.

--f46d04083aad240c5a04d14dcea7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 20, 2012 at 12:43 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wro=
te:</div>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204=
);border-left-style:solid;padding-left:1ex">&gt; you may find yourself in a=
 situation needing to parse a protobuf<br>

&gt; message in a web browser<br><span style=3D"font-family:arial,sans-seri=
f;font-size:13px">Nothing stops you converting them into whatever form you =
want on the<br></span><span style=3D"font-family:arial,sans-serif;font-size=
:13px">server side. If you don&#39;t care about the signature checking then=
 it&#39;s<br>

</span><span style=3D"font-family:arial,sans-serif;font-size:13px">no probl=
em to use a server. If you do then you&#39;d need to ship all the<br></span=
><span style=3D"font-family:arial,sans-serif;font-size:13px">code for verif=
ying signatures that to the client anyway, at which<br>

</span><span style=3D"font-family:arial,sans-serif;font-size:13px">point a =
small protobuf parser is hardly a deal killer.</span></blockquote><div><br>=
</div><div style>No, it&#39;s not a killer...just a hassle. =A0JSON is conv=
enient and ubiquitous and there is something to be said for that (and I wan=
ted to point out that the JOSE objection was invalid). =A0Protobufs are nic=
e and efficient, but who cares. =A0You&#39;re talking about direct communic=
ations rather than something that will be bounced around every node in the =
mesh network. =A0I don&#39;t really care much either way, it&#39;s not wort=
h debating. =A0I&#39;m just thankful no one is arguing for XML or IIOP. =A0=
:) =A0</div>

</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">

<div class=3D"im">&gt; ...like what about the casual user that wants to cre=
ate a payment request to<br>
&gt; send to their friend over email<br>
<br>
</div>They can send an unsigned payment request. Note that if you mail it a=
s<br>
an attachment from a competent, up to date email provider then the<br>
attachment isn&#39;t really unsigned. The whole thing is covered by the<br>
emails DKIM signature which is applied transparently by the ESP. If<br>
the signature fails to verify then the mail client can show that or<br>
treat the mail differently (as Gmail does). This is easy to use for<br>
the end user - they don&#39;t have to think about cryptography or PKI. As<b=
r>
long as their email account is secure then they can send signed mails<br>
asserting to their identity.<br></blockquote><div><br></div><div style>This=
 leaves too much to chance for my taste. =A0Forget email, what about jabber=
, ICQ, skype, IRC? =A0Email is just one communications medium, there are ma=
ny others for which there would be no assurance that the payment request ha=
sn&#39;t been tampered with. =A0You could at a minimum allow a person to cr=
eate a normal ECC key, but have it used as an identity in communications ra=
ther than a payment address. =A0You store it in a separate file in ~/.bitco=
in/id =A0...you don&#39;t have to solve the whole set of PKI problems, peop=
le could exchange identities using any secure channel they are comfortable =
with (email + phone verification of a short hash id would be sufficient). =
=A0In another scenario, an id could be made available over https, using the=
 normal SSL certificate and CA infrastructure to verify authenticity. =A0Th=
is way all messages could be signed and/or encrypted without the user havin=
g to go out of their way to use external tools or infrastructure that is of=
ten not very user friendly. =A0You also need encryption for the &quot;chequ=
e&quot; feature...asking people to use GPG would be too much of a burden (a=
nd email DKIM doesn&#39;t offer encryption).</div>

<div style><br></div><div style>&gt;&gt;&gt; wandering off topic &gt;&gt;&g=
t;</div><div style>Indeed, &quot;cheques&quot; could become the dominant me=
thod of person to person payments...first, you would obtain someone&#39;s i=
d, which you might already have on file (rather than obtaining a bitcoin ad=
dress), then you would generate a &quot;cheque&quot; for the amount desired=
 and send it to them...the recipient then has full control over what addres=
s they want to sweep the funds to as well as whether they&#39;d like to inc=
lude a miner fee to speed the confirmation along. Despite the fact that you=
 may send many payments to the same identity, the only thing showing up on =
the p2p network and the block chain is the one time use address for the che=
que and the recipient&#39;s wallet address. =A0This means the recipient has=
 much more control over the address policy used (compared with simply givin=
g out a bitcoin address that may be reused).</div>

<div>&lt;&lt;&lt;=A0</div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r=
gb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=3D"im"=
>
&gt; Refund addresses...this is not going to be as useful as people might<b=
r>
&gt; think...most refunds that bitpay needs to process happen days or even =
months<br>
&gt; after the initial purchase<br>
<br>
</div>Useful feedback, thanks. Still, there may be other types of merchants=
<br>
for whom it&#39;s useful, and many users won&#39;t change their wallet. It<=
br>
certainly simplifies things if you can present the refund address and<br>
give a one-click option to use it. If the user wants to use a<br>
different address, then they can go onto the slow/complicated path.<br>
<br>
This current spec deliberately punts on the topic of identifying end<br>
users. It&#39;s a difficult problem.<br></blockquote><div><br></div><div st=
yle>I know, but as I was responding, I began to realize this is a mistake. =
=A0It&#39;s worthwhile to tackle that problem first...if done right, it wou=
ld pay huge dividends. =A0Also, identity is one thing, an elaborate trust b=
ased identity verification system (like CA&#39;s) is a whole other thing. =
=A0I think the former is pretty simple actually...and it&#39;s all that&#39=
;s really needed for the time being (as I alluded, a bitcoin identity could=
 be communicated or verified using the existing X.509/CA infrastructure if =
desired...you could also use the PGP infrastructure).</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div class=3D"im">
&gt; I like the use of merchant_data...this means that you no longer will n=
eed a<br>
&gt; unique bitcoin address for every invoice.<br>
<br>
</div>It&#39;s still a good idea to use one for privacy reasons. </blockquo=
te><div><br></div><div style>Actually, I was speaking more in terms of rely=
ing on the address to match up a transaction to an invoice. =A0The merchant=
_data field frees you from having to do that.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">The merchant<br>
data is there so you can stuff whatever state you want into it. So<br>
it&#39;s like cookies. You don&#39;t have to keep state on the server side.=
<br>
Just encrypt/sign it, put it in the invoice, and when you get a<br>
payment message back there&#39;s no need to do database lookups or<br>
anything, you can just do some crypto and know who is submitting it.<br></b=
lockquote><div><br></div><div style>Yeah, that&#39;s neat...I hadn&#39;t th=
ought of that possibility. =A0</div><div>=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class=3D"im">
&gt; Generally speaking, I&#39;m not a fan of embedding things like that<br=
>
<br>
</div>What&#39;s wrong with it? Isn&#39;t your proposal more complex? I don=
&#39;t see<br>
why it&#39;s better than just embedding it.<br></blockquote><div><br></div>=
<div style>It&#39;s not a big deal, I just think a referential model is mor=
e general than embedding objects within each other.</div><div>=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">

<div class=3D"im">
&gt; The Receipt should be signed...it could be used as proof of payment by=
<br>
&gt; wallets.<br>
<br>
</div>There&#39;s no Receipt message, a SignedPaymentRequest + transactions=
 that<br>
pay to the requested outputs are together the proof of payment.<br></blockq=
uote><div><br></div><div style>Ah, I see it was renamed PaymentACK...the po=
int of signing a PaymentACK is that while you could prove that you paid acc=
ording to a PaymentRequest, a signed PaymentACK is proof that the recipient=
 acknowledged you have made that payment.</div>

<div><br></div></div>
</div></div>

--f46d04083aad240c5a04d14dcea7--