summaryrefslogtreecommitdiff
path: root/36/1502a08dc3a9f3a7ec4142e9297cb7d35747a2
blob: 29127c4bf5c46f49842a1ca100598e53a89d1598 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1Tlk9l-0001DF-IY
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 17:43:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.43 as permitted sender)
	client-ip=209.85.219.43; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f43.google.com; 
Received: from mail-oa0-f43.google.com ([209.85.219.43])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Tlk9k-0007Uw-HG
	for bitcoin-development@lists.sourceforge.net;
	Thu, 20 Dec 2012 17:43:41 +0000
Received: by mail-oa0-f43.google.com with SMTP id k1so3661462oag.2
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 20 Dec 2012 09:43:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.172.164 with SMTP id bd4mr8622519oec.51.1356025415142; Thu,
	20 Dec 2012 09:43:35 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Thu, 20 Dec 2012 09:43:34 -0800 (PST)
In-Reply-To: <CADb9v0K9xD+ndB-dJDkmPOuo1omrtMk3WTo238OjVcWoQ-CmXA@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>
Date: Thu, 20 Dec 2012 18:43:34 +0100
X-Google-Sender-Auth: eDiEeB1tqUujt3NflFhJW7nbs4M
Message-ID: <CANEZrP162Q=hoqBQvLPm6rT=xNHMOtau42gDzRS4ddEtMFk5Uw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Stephen Pair <stephen@bitpay.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.5 (-)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1Tlk9k-0007Uw-HG
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 17:43:41 -0000

Thanks for the thoughts. For those who don't know, Stephen works for BitPay.

> My first observation is that the proposal is too heavily oriented around a
> merchant/customer interaction.

The term "merchant" is just being used to mean the entity requesting
the payment. I'm hopeful that in future mobile wallets will be
creating these messages where today they'd make URLs and QRcodes. So
it's definitely intended for person to person payments too.

> 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.

> ...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.

> 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. Whereas many merchants have SSL
certs, most end users don't have published keys in any useful form. By
far the easiest way for 99% of people to generate a signed message is
to send email that's signed by DKIM (from gmail, hotmail, yahoo, other
providers etc). Then it's all transparent and behind the scenes. Their
identity is their email address.

So for BitPays scenario, you could require an email to be sent by the
end user containing new instructions. Your MTA can show you whether
the mail is correctly DKIM signed or not when deciding whether to
follow the instructions.

> But, if the recipient never cashes the check, the sender could pull those
> funds back after a certain period of time.

Yeah, I like the term "check"/"cheque" for that concept of a reversible payment.

> 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. 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.

> 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.

> 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.

Re a new URI scheme. Interesting idea, thanks for the suggestion. It
seemed like it'd be easier for merchants to integrate if a single
linked worked for all wallet implementations/versions. But I guess we
could do both schemes, even.