path: root/61/fc93d9dc64d0c32428e9c754348f08e77a8ad1

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephen@bitpay.com>) id 1TljNx-0006fA-Mb
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 16:54:17 +0000
Received: from mail-la0-f45.google.com ([209.85.215.45])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1TljNt-0006hu-Ef
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 16:54:17 +0000
Received: by mail-la0-f45.google.com with SMTP id p9so3385453laa.18
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 20 Dec 2012 08:54:06 -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:content-type:x-gm-message-state;
	bh=TKphXSstGECetuPvUQbwf9XgIeHa7wNWhgYcumABQ6Y=;
	b=FizoMLSibG0X6Z0tv+hr2WjxPBrIugDH7bYKOIaIkv+8qXm3QvgOYAvHZqT18w5qd7
	2U8fw5Ogf7uvn+6TYCFHyq+aOoPPcpPVacmjswnaCXxsSqUA1QZJ+p5HTUl5exQTNwSf
	BIfUfclofxWZbG2n1SvP9t9F8cr1PwLNvf7xJxkmRqh02W+fC0fzDf8SECwkECUx/KEp
	3f42CEIBkOKWRteg9ewlEcnXj2E0ftnUd2uSbR5HtzDlUSbql5xwnAYGm3AYWvaGQDPU
	MutoRnDRS8nI7q+I7PEe1g0XtyPsn+g0CfkcWRy3SbzTtve4VHpTW/E4Jvux/LSN5xsX
	lb6A==
X-Received: by 10.112.17.129 with SMTP id o1mr4114716lbd.54.1356022446105;
	Thu, 20 Dec 2012 08:54:06 -0800 (PST)
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
	[209.85.215.46])
	by mx.google.com with ESMTPS id v7sm3654575lbj.13.2012.12.20.08.54.03
	(version=TLSv1/SSLv3 cipher=OTHER);
	Thu, 20 Dec 2012 08:54:04 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id p5so3378249lag.19
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 20 Dec 2012 08:54:02 -0800 (PST)
Received: by 10.152.105.103 with SMTP id gl7mr9364760lab.10.1356022442388;
	Thu, 20 Dec 2012 08:54:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.114.17.231 with HTTP; Thu, 20 Dec 2012 08:53:22 -0800 (PST)
X-Originating-IP: [71.204.90.78]
In-Reply-To: <CABsx9T1QjDfg-hKorJCk8Sdhf0fw9qQjV8R8EPNvU0m0nQF3tw@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>
From: Stephen Pair <stephen@bitpay.com>
Date: Thu, 20 Dec 2012 11:53:22 -0500
Message-ID: <CADb9v0K9xD+ndB-dJDkmPOuo1omrtMk3WTo238OjVcWoQ-CmXA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=f46d040714a7fc6d5204d14b938c
X-Gm-Message-State: ALoCoQmslo1sfOMaq+FLydFkvDT13YLdlyi/8qPec74McwhG7L0mG8JZ36EmwAw8zCXMVf6z2nXt
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: 1TljNt-0006hu-Ef
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 16:54:17 -0000

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

Here are my (mostly half baked) thoughts on the payments protocol proposal.

My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction.  I think it's equally important to consider
the person to person scenarios.  It would be very cool if people could
send/receive payments by copying and pasting stuff on facebook or email
(you can kind of do it now, but it's not safe unless you go to
extraordinary lengths using PGP signatures and the like).

Protobufs vs JSON: Protobufs are fine, although I will mention that the
serialization/JOSE arguments are irrelevant...you only need that if you
need a reliable way of signing an in memory object structure...in this case
you would be signing a serialized form of the object...the recipient
doesn't have to be able to reproduce the serialized form, they only need to
verify the signature on the already serialized bytes...I see protobufs as a
good serialization format for storage, while JSON being more practical for
communications in a web oriented environment...with protobufs & a web
wallet, you may find yourself in a situation needing to parse a protobuf
message in a web browser...the protobuf parsing and serializing code is
just going to add bloat to the web page...personally, I probably would have
gone with JSON, but hey, I'm not writing the code.

X.509 - nasty, but maybe ok ...as long as you can add root CAs to your
Bitcoin client or explicitly trust a certificate, I don't see that it poses
any privacy issues...but there are some other things to think about here
...like what about the casual user that wants to create a payment request
to send to their friend over email (wrapped in a clear text block similar
to PGP...it could also be sent as a file attachment)?  Are you now
requiring them to go and setup a certificate?  Btw, I really like the use
of a payment request in this manner because you have a signed payment
request that can be verified against an address book of known identities.
 This could be much safer than simply emailing an unsigned bitcoin address
around.

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...in that span of time, people can change
wallets, rendering such a refund address useless...so, as I think about the
situation, we would still need to contact the buyer to confirm a refund
address anyway.  What we really need is to verify the identity of the
person we're potentially sending the refund to...we need a way of
determining that the person we're sending the refund to is the same person
that paid the original invoice.  Bitcoin addresses are identities, but they
are too low level.  HD wallets come to mind...the top level or intermediate
levels of a deterministic hierarchy could be used for identity
purposes...but it also seems like it might be conflating payments and
identity (which for many reasons you might want to keep separate).  What if
bitcoin clients could manage one or more identities used for the purpose of
communications?  You could have a bitcoin identity file that could be used
by multiple wallets.  These identities would be used for signing messages
and verifying the authenticity of communications...when sending a payment,
instead of a refund address, you would include one of these identities
which could later be used to confirm a refund address.  In fact, the refund
would be processed by the buyer generating another payment request message
signed by the identity used in the original payment.

People would understand that their identities are important for
communications and they would keep those even when changing to new wallets
and such (identities could be stored in ~/.bitcoin/id or something
(encrypted of course)).

There are some other interesting possibilities if messaging and identities
are done right...for example, I could add "check" feature (analogous to
paper checks).  It would work like this...you create a transaction that
spends to a newly generated address...you put that transaction, along with
the private key into an encrypted container (sent to the identity of the
person you want to pay).  The recipient can open it and their wallet would
go ahead and generate and broadcast a transaction moving the funds into
their wallet (optionally including a fee).  But, if the recipient never
cashes the check, the sender could pull those funds back after a certain
period of time.  This also eliminates the possibility of accidentally
sending the funds to the wrong address (or an old address) and the bitcoins
being forever lost...the recipient can sweep the transaction into any
wallet of their choice.

As I'm writing this, I'm beginning to wonder if the identity management
problem is unavoidable.  Maybe that needs to be dealt with first.  It would
enable so many other interesting possibilities.

I like the use of merchant_data...this means that you no longer will need a
unique bitcoin address for every invoice.

In the signed invoice structure, why embed the serialized invoice?  Why not
make that a reference using a hash?  Generally speaking, I'm not a fan of
embedding things like that.  You could have an over-arching structure
called Message which is just "repeated bytes objects" (in protobuf lingo)
...references between objects would use a hash and the first object would
be treated as the message.  In a payment request message, the
SignedPaymentRequest would be the first object, the PaymentRequest the
second.

I think the Payment structure should refer to the SignedPaymentRequest (by
its hash) instead of the merchant_data...you can of course access the
merchant_data through the SignedPaymentRequest.  I suppose you could always
index payment requests based on the merchant_data, but it just seems
cleaner to refer back the the signed payment request when sending a payment.

You might want to include an optional memo for each output...I could
imagine including one output that says "Don't forget to tip your
waiter"...any amount sent to that address could go directly to the waiter's
wallet.

What about payments from multiple wallets?  We see this a lot.  I think
this scheme would handle it ok, but just want to mention it.  I can imagine
someone paying first from one wallet, then the invoice webpage updates with
a clickable link to a new PaymentRequest for the remaining amount.

The Receipt should be signed...it could be used as proof of payment by
wallets.

Finally, I've seen seen suggestions to tack on a payment request URI to the
current bitcoin: URI for backward compatibility...I say no.  A bitcoin URI
already has a lot of data (especially if it includes a memo)...this makes
QR codes more dense and hence more difficult to scan...I say we stake a
claim on the "pay" URI .... pay:https://somewhere.com/payment/94kd83  ...or
for a clickable link, you could embed it right on the web page, eliminating
the need for a second https request... pay:data:<PaymentRequestMessage>
 ...and finally, to further shorten the URI, https could be assumed if the
protocol is omitted ... pay:somewhere.com/payment/94kd83

We can deal with backward compatibility by including a link on invoices to
display an old style bitcoin payment address.

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

<div dir=3D"ltr"><div style>Here are my (mostly half baked) thoughts on the=
 payments protocol proposal.</div><div><br></div><div style>My first observ=
ation is that the proposal is too heavily oriented around a merchant/custom=
er interaction. =A0I think it&#39;s equally important to consider the perso=
n to person scenarios. =A0It would be very cool if people could send/receiv=
e payments by copying and pasting stuff on facebook or email (you can kind =
of do it now, but it&#39;s not safe unless you go to extraordinary lengths =
using PGP signatures and the like).</div>

<div><br></div><div>Protobufs vs JSON: Protobufs are fine, although I will =
mention that the serialization/JOSE arguments are irrelevant...you only nee=
d that if you need a reliable way of signing an in memory object structure.=
..in this case you would be signing a serialized form of the object...the r=
ecipient doesn&#39;t have to be able to reproduce the serialized form, they=
 only need to verify the signature on the already serialized bytes...I see =
protobufs as a good serialization format for storage, while JSON being more=
 practical for communications in a web oriented environment...with protobuf=
s &amp; a web wallet, you may find yourself in a situation needing to parse=
 a protobuf message in a web browser...the protobuf parsing and serializing=
 code is just going to add bloat to the web page...personally, I probably w=
ould have gone with JSON, but hey, I&#39;m not writing the code.<br>

</div><div><br></div>X.509 - nasty, but maybe ok ...as long as you can add =
root CAs to your Bitcoin client or explicitly trust a certificate, I don&#3=
9;t see that it poses any privacy issues...but there are some other things =
to think about here ...like what about the casual user that wants to create=
 a payment request to send to their friend over email (wrapped in a clear t=
ext block similar to PGP...it could also be sent as a file attachment)? =A0=
Are you now requiring them to go and setup a certificate? =A0Btw, I really =
like the use of a payment request in this manner because you have a signed =
payment request that can be verified against an address book of known ident=
ities. =A0This could be much safer than simply emailing an unsigned bitcoin=
 address around.<div>

<div><br></div><div style>Refund addresses...this is not going to be as use=
ful as people might think...most refunds that bitpay needs to process happe=
n days or even months after the initial purchase...in that span of time, pe=
ople can change wallets, rendering such a refund address useless...so, as I=
 think about the situation, we would still need to contact the buyer to con=
firm a refund address anyway. =A0What we really need is to verify the ident=
ity of the person we&#39;re potentially sending the refund to...we need a w=
ay of determining that the person we&#39;re sending the refund to is the sa=
me person that paid the original invoice. =A0Bitcoin addresses are identiti=
es, but they are too low level. =A0HD wallets come to mind...the top level =
or intermediate levels of a deterministic hierarchy could be used for ident=
ity purposes...but it also seems like it might be conflating payments and i=
dentity (which for many reasons you might want to keep separate). =A0What i=
f bitcoin clients could manage one or more identities used for the purpose =
of communications? =A0You could have a bitcoin identity file that could be =
used by multiple wallets. =A0These identities would be used for signing mes=
sages and verifying the authenticity of communications...when sending a pay=
ment, instead of a refund address, you would include one of these identitie=
s which could later be used to confirm a refund address. =A0In fact, the re=
fund would be processed by the buyer generating another payment request mes=
sage signed by the identity used in the original payment. =A0</div>

<div style><br></div><div style>People would understand that their identiti=
es are important for communications and they would keep those even when cha=
nging to new wallets and such (identities could be stored in ~/.bitcoin/id =
or something (encrypted of course)).</div>

<div style><br></div><div style>There are some other interesting possibilit=
ies if messaging and identities are done right...for example, I could add &=
quot;check&quot; feature (analogous to paper checks). =A0It would work like=
 this...you create a transaction that spends to a newly generated address..=
.you put that transaction, along with the private key into an encrypted con=
tainer (sent to the identity of the person you want to pay). =A0The recipie=
nt can open it and their wallet would go ahead and generate and broadcast a=
 transaction moving the funds into their wallet (optionally including a fee=
). =A0But, if the recipient never cashes the check, the sender could pull t=
hose funds back after a certain period of time. =A0This also eliminates the=
 possibility of accidentally sending the funds to the wrong address (or an =
old address) and the bitcoins being forever lost...the recipient can sweep =
the transaction into any wallet of their choice.<br>

</div><div style><br></div><div style>As I&#39;m writing this, I&#39;m begi=
nning to wonder if the identity management problem is unavoidable. =A0Maybe=
 that needs to be dealt with first. =A0It would enable so many other intere=
sting possibilities.</div>

<div style><br></div><div style>I like the use of merchant_data...this mean=
s that you no longer will need a unique bitcoin address for every invoice.<=
/div><div style><br></div><div style>In the signed invoice structure, why e=
mbed the serialized invoice? =A0Why not make that a reference using a hash?=
 =A0Generally speaking, I&#39;m not a fan of embedding things like that. =
=A0You could have an over-arching structure called Message which is just &q=
uot;repeated bytes objects&quot; (in protobuf lingo) ...references between =
objects would use a hash and the first object would be treated as the messa=
ge. =A0In a payment request message, the SignedPaymentRequest would be the =
first object, the PaymentRequest the second.</div>

<div style><br></div><div style>I think the Payment structure should refer =
to the SignedPaymentRequest (by its hash) instead of the merchant_data...yo=
u can of course access the merchant_data through the SignedPaymentRequest. =
=A0I suppose you could always index payment requests based on the merchant_=
data, but it just seems cleaner to refer back the the signed payment reques=
t when sending a payment.</div>

<div style><br></div><div style>You might want to include an optional memo =
for each output...I could imagine including one output that says &quot;Don&=
#39;t forget to tip your waiter&quot;...any amount sent to that address cou=
ld go directly to the waiter&#39;s wallet.</div>

<div style><br></div><div style>What about payments from multiple wallets? =
=A0We see this a lot. =A0I think this scheme would handle it ok, but just w=
ant to mention it. =A0I can imagine someone paying first from one wallet, t=
hen the invoice webpage updates with a clickable link to a new PaymentReque=
st for the remaining amount.</div>

<div style><br></div><div style>The Receipt should be signed...it could be =
used as proof of payment by wallets.</div><div style><br></div><div style>F=
inally, I&#39;ve seen seen suggestions to tack on a payment request URI to =
the current bitcoin: URI for backward compatibility...I say no. =A0A bitcoi=
n URI already has a lot of data (especially if it includes a memo)...this m=
akes QR codes more dense and hence more difficult to scan...I say we stake =
a claim on the &quot;pay&quot; URI .... pay:<a href=3D"https://somewhere.co=
m/payment/94kd83">https://somewhere.com/payment/94kd83</a> =A0...or for a c=
lickable link, you could embed it right on the web page, eliminating the ne=
ed for a second https request... pay:data:&lt;PaymentRequestMessage&gt; =A0=
...and finally, to further shorten the URI, https could be assumed if the p=
rotocol is omitted ... pay:<a href=3D"http://somewhere.com/payment/94kd83">=
somewhere.com/payment/94kd83</a></div>

<div><br></div><div style>We can deal with backward compatibility by includ=
ing a link on invoices to display an old style bitcoin payment address.</di=
v><div><br></div>
</div></div>

--f46d040714a7fc6d5204d14b938c--