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
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <peter@coinlab.com>) id 1TJ6dz-00031V-6v
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 17:52:31 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.223.175 as permitted sender)
client-ip=209.85.223.175; envelope-from=peter@coinlab.com;
helo=mail-ie0-f175.google.com;
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TJ6dy-0005Qw-4t
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 17:52:31 +0000
Received: by iebc13 with SMTP id c13so16235162ieb.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Oct 2012 10:52:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-type:x-gm-message-state;
bh=Z2Bc2Mw4g3B2EeWCn4o+PHfHLocvKp8+9J0yHpJyAuE=;
b=aA3Hjn/Zb3kkPx3fPob9LrQ7J1UGlPHbWjZoRbZzKzulCh89kZSSZk2uyQO0cLUZhV
BMnlJGWPm4pz2pG9j1PTYRpboi4S9coxA7s9STZn1jHT3Za8V4BvGWihlxzGgKltjGfX
HExuQOKXoALxIm5+cgNh+XabztunFqQ/1MzVC40dQnAR3eogofOW9z0EiWL41hRYqoI/
TeDwHIXpeS4Y3mppqHt9V3n+Re3ws/vkOpJ79KWjUNRgDsa9EpJ6S+MGbbiOs1JpquR2
EdCutrsrcNaroDN6o0Up08Xsuqz6SBdzZQCnJIvcR4QgUiF/nDowT7PO70csdyvxLXaW
JJPg==
Received: by 10.50.11.194 with SMTP id s2mr9723424igb.24.1349200344607; Tue,
02 Oct 2012 10:52:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.216.137 with HTTP; Tue, 2 Oct 2012 10:52:04 -0700 (PDT)
In-Reply-To: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
References: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
<CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
From: Peter Vessenes <peter@coinlab.com>
Date: Tue, 2 Oct 2012 10:52:04 -0700
Message-ID: <CAMGNxUuqyASMxu6DyL0n1_k7+Xt-3yeXbP8txiRjdUFrQtHNjA@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f646b07456b2504cb172f51
X-Gm-Message-State: ALoCoQm6Q8OIwiJO8bC42etY9hi1r3Und9zndilSSwRTC9+4f+wa6UkfdH3bsvuApGLqtiuuKu2W
X-Spam-Score: -0.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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1TJ6dy-0005Qw-4t
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment protocol thoughts
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: Tue, 02 Oct 2012 17:52:31 -0000
--e89a8f646b07456b2504cb172f51
Content-Type: text/plain; charset=ISO-8859-1
There are tons of scenarios, some discussed here on this list previously,
which would benefit from out of band messages and notes.
This is small, but an interesting tidbit from BTC Foundation payments;
roughly 3-5% of our initial members double-spent. WOW, that's terrible.
I presume that's because they use web wallets without double-click
prevention. But, seriously! A tiny UI issue that's a big deal in an
irrevocable payment system.
On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <gavinandresen@gmail.com>wrote:
> I agree we need a payment protocol, but instead of thinking of all of the
> things we might possibly want I would like to solve a few boring problems
> that we have right now.
>
> Absolutely critical:
>
> + Bitcoin addresses by themselves are insecure against man-in-the-middle
> attacks. We need a payment protocol so if you get a donation link for
> "Bitcoin Foundation" in an email message and click on it you can be
> reasonably certain that your coins will actually go to the Foundation and
> not some hacker at your ISP that modified the email message.
>
>
I'm trying but can't think of a lightweight solution to this off the top of
my head. Not that that proves much.
> + After sending payment I should have a receipt that proves I followed the
> payee's instructions, so if the payee says they never received the funds I
> can prove that it wasn't my fault.
>
>
+ Protocol for gathering signatures from multiple devices
> (extension/variation of the basic payment protocol, I think).
>
> With the foundation trying to operate without bank accounts, I think it
comes into clarity for me just how innovative and incredibly awesome this
would be for financial controls for companies. Imagine the bookkeeper
inputting payments, and the owner (or 2 of 3 owners) approving them. I can
even imagine large member groups having 2/3 or majority spend rules.
When we talk about stuff like this, I come back around to thinking there
should be many different GUIs -- this use case is more business-y, it's
stuff like this that I always think about the bitcoin testing project
helping provide -- a standard backend that a bookkeeping GUI could go on
top of..
> Not absolutely necessary, but I think v1 should have it anyway:
>
> + Where-to-send-refund information included with payments, so
> overpayments/refunds can be handled efficiently and displayed intelligently
> in the customer's wallet.
>
>
> Everything else I think can wait.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
------------------------------
[image: CoinLab Logo]PETER VESSENES
CEO
*peter@coinlab.com * / 206.486.6856 / SKYPE: vessenes
811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104
--e89a8f646b07456b2504cb172f51
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
There are tons of scenarios, some discussed here on this list previously, w=
hich would benefit from out of band messages and notes.=A0<div><br></div><d=
iv>This is small, but an interesting tidbit from BTC Foundation payments; r=
oughly 3-5% of our initial members double-spent. WOW, that's terrible.<=
/div>
<div><br></div><div>I presume that's because they use web wallets witho=
ut double-click prevention. But, seriously! A tiny UI issue that's a bi=
g deal in an irrevocable payment system.</div><div><br><div><br><div class=
=3D"gmail_quote">
On Tue, Oct 2, 2012 at 10:43 AM, Gavin Andresen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">gavinandresen@gmail=
.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I agree we need a payment protocol, but instead of thinking of all of =
the things we might possibly want I would like to solve a few boring proble=
ms that we have right now.</div><div><br></div><div>Absolutely critical:</d=
iv>
<div><br></div><div>+ Bitcoin addresses by themselves are insecure against =
man-in-the-middle attacks. We need a payment protocol so if you get a donat=
ion link for "Bitcoin Foundation" in an email message and click o=
n it you can be reasonably certain that your coins will actually go to the =
Foundation and not some hacker at your ISP that modified the email message.=
</div>
<div><br></div></blockquote><div><br></div><div>I'm trying but can'=
t think of a lightweight solution to this off the top of my head. Not that =
that proves much.</div><div>=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div></div><div>+ After sending payment I should have a receipt that proves=
I followed the payee's instructions, so if the payee says they never r=
eceived the funds I can prove that it wasn't my fault.</div><div>=A0</d=
iv>
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div></div><div>+ Protocol for =
gathering signatures from multiple devices (extension/variation of the basi=
c payment protocol, I think).</div>
<div><br></div></blockquote><div>With the foundation trying to operate with=
out bank accounts, I think it comes into clarity for me just how innovative=
and incredibly awesome this would be for financial controls for companies.=
Imagine the bookkeeper inputting payments, and the owner (or 2 of 3 owners=
) approving them. I can even imagine large member groups having 2/3 or majo=
rity spend rules.=A0</div>
<div><br></div><div>When we talk about stuff like this, I come back around =
to thinking there should be many different GUIs -- this use case is more bu=
siness-y, it's stuff like this that I always think about the bitcoin te=
sting project helping provide -- a standard backend that a bookkeeping GUI =
could go on top of..=A0</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div></div><div>Not absolutely=
necessary, but I think v1 should have it anyway:</div>
<div><br></div><div>+ Where-to-send-refund information included with paymen=
ts, so overpayments/refunds can be handled efficiently and displayed intell=
igently in the customer's wallet.</div><div><br></div><div><br></div>
<div>Everything else I think can wait.</div><span class=3D"HOEnZb"><font co=
lor=3D"#888888"><div><br></div>-- <br>--<br>Gavin Andresen<br><br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
Don't let slow site performance ruin your business. Deploy New Relic AP=
M<br>
Deploy New Relic app performance management and know exactly<br>
what is happening inside your Ruby, Python, PHP, Java, and .NET app<br>
Try New Relic at no cost today and get our sweet Data Nerd shirt too!<br>
<a href=3D"http://p.sf.net/sfu/newrelic-dev2dev" target=3D"_blank">http://p=
.sf.net/sfu/newrelic-dev2dev</a><br>_______________________________________=
________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><hr styl=
e=3D"font-family:Times;font-size:medium;border-right-width:0px;border-botto=
m-width:0px;border-left-width:0px;border-top-style:solid;border-top-color:r=
gb(204,204,204);margin:10px 0px">
<p style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1=
em"><span style=3D"color:rgb(50,90,135);text-transform:uppercase"><img src=
=3D"http://coinlab.com/static/images/email_logo.jpg" align=3D"right" alt=3D=
"CoinLab Logo" width=3D"130">PETER=A0<span style=3D"font-weight:bold">VESSE=
NES=A0</span><br>
<span style=3D"color:rgb(96,58,23);font-size:0.8em">CEO</span></span></p><p=
style=3D"font-size:medium;font-family:Helvetica,sans-serif;line-height:1em=
"><span style=3D"color:rgb(96,58,23);font-size:0.9em"><strong><a href=3D"ma=
ilto:peter@coinlab.com" style=3D"text-decoration:none;color:rgb(96,58,23)" =
target=3D"_blank">peter@coinlab.com</a>=A0</strong>=A0/=A0=A0206.486.6856 =
=A0/=A0<span style=3D"font-size:0.7em;text-transform:uppercase">SKYPE:</spa=
n>=A0vessenes=A0</span><br>
<span style=3D"color:rgb(96,58,23);font-size:0.7em;text-transform:uppercase=
">811 FIRST AVENUE =A0/=A0 SUITE 480 =A0/=A0 SEATTLE, WA 98104</span></p><b=
r>
</div></div>
--e89a8f646b07456b2504cb172f51--
|
