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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1TJ6Vi-0007Jg-Kx
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 17:43:58 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TJ6Vh-00059E-VC
for bitcoin-development@lists.sourceforge.net;
Tue, 02 Oct 2012 17:43:58 +0000
Received: by weyt44 with SMTP id t44so3952531wey.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Oct 2012 10:43:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.167.135 with SMTP id i7mr9687790wel.97.1349199831803; Tue,
02 Oct 2012 10:43:51 -0700 (PDT)
Received: by 10.194.17.138 with HTTP; Tue, 2 Oct 2012 10:43:51 -0700 (PDT)
In-Reply-To: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
References: <CANEZrP3aArZV1jCL8OsksGxQO03Cs=CKM_4L3NB1=qGo=GMHdA@mail.gmail.com>
Date: Tue, 2 Oct 2012 13:43:51 -0400
Message-ID: <CABsx9T0f8By2g9zKzfB7FLiMh6_aMk2iGO1Uesdqib_-Ok-1sA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=0016e6541f94b4a74304cb171044
X-Spam-Score: -0.6 (/)
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
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1TJ6Vh-00059E-VC
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:43:58 -0000
--0016e6541f94b4a74304cb171044
Content-Type: text/plain; charset=ISO-8859-1
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.
+ 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).
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
--0016e6541f94b4a74304cb171044
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<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><div>+ After sending payment I should have a receipt that pr=
oves I followed the payee's instructions, so if the payee says they nev=
er received the funds I can prove that it wasn't my fault.</div><div>
<br></div><div>+ Protocol for gathering signatures from multiple devices (e=
xtension/variation of the basic payment protocol, I think).</div><div><br><=
/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><div><br></div>-- <br>--<br>Gav=
in Andresen<br><br>
--0016e6541f94b4a74304cb171044--
|
