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
|
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 <mh.in.england@gmail.com>) id 1W8pBm-000165-SC
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 10:49:42 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.45 as permitted sender)
client-ip=209.85.219.45; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f45.google.com;
Received: from mail-oa0-f45.google.com ([209.85.219.45])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W8pBk-0002S4-W4
for bitcoin-development@lists.sourceforge.net;
Thu, 30 Jan 2014 10:49:42 +0000
Received: by mail-oa0-f45.google.com with SMTP id i11so3410061oag.4
for <bitcoin-development@lists.sourceforge.net>;
Thu, 30 Jan 2014 02:49:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.213.166 with SMTP id nt6mr800236obc.53.1391078972732;
Thu, 30 Jan 2014 02:49:32 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Thu, 30 Jan 2014 02:49:32 -0800 (PST)
In-Reply-To: <52E9E787.8080304@borboggle.com>
References: <52E9E787.8080304@borboggle.com>
Date: Thu, 30 Jan 2014 11:49:32 +0100
X-Google-Sender-Auth: 5jES72YOIQS62TVHMmXcsLBT8F4
Message-ID: <CANEZrP0soR0xRqW=vsKaL__HRuWstA5vW=6_JkGZm=8wkm8Q3g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chuck <chuck+bitcoindev@borboggle.com>
Content-Type: multipart/alternative; boundary=001a11c2e60a063d4a04f12dd09d
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 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
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1W8pBk-0002S4-W4
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 message delivery reliability
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, 30 Jan 2014 10:49:43 -0000
--001a11c2e60a063d4a04f12dd09d
Content-Type: text/plain; charset=UTF-8
Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck <chuck+bitcoindev@borboggle.com>wrote:
> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>
That's all you need to prove payment, yes.
> In the well-behaved case, I presume the point is to help the
> merchant associate some arbitrary data with the purchase as well as
> provide a refunding address for the customer.
That's right (+memo). And to provide an additional hook for future
features, like recurring billing, ECDH key agreements etc.
> In Step 3, it's critical the customer sign the message with the private
> key of the refund address, so that the merchant can be confident the
> refund address is correct.
>
Refund addresses as specced currently are optional. For instance bitcoinj
currently doesn't use them and won't until HD wallets support is done.
Let's get some practical experience with what we've got so far. We can
evolve PaymentRequest/Payment/PaymentACK in the right direction with
backwards compatible upgrades, I am hoping.
--001a11c2e60a063d4a04f12dd09d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Chuck,<div><br></div><div>Both Bitcoin Core and bitcoin=
j are about to ship with the protocol as-is, so any changes from this point=
on have to be backwards compatible.</div><div><br></div><div class=3D"gmai=
l_extra">
<div class=3D"gmail_quote">On Thu, Jan 30, 2014 at 6:47 AM, Chuck <span dir=
=3D"ltr"><<a href=3D"mailto:chuck+bitcoindev@borboggle.com" target=3D"_b=
lank">chuck+bitcoindev@borboggle.com</a>></span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
I presume the receipt R=3D(PaymentRequest,[transactions]) would suffice.<br=
></blockquote><div><br></div><div>That's all you need to prove payment,=
yes.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the well-behaved case, I presume the point is to help the<br>
merchant associate some arbitrary data with the purchase as well as<br>
provide a refunding address for the customer. </blockquote><div><br></div><=
div>That's right (+memo). And to provide an additional hook for future =
features, like recurring billing, ECDH key agreements etc.</div><div>=C2=A0=
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">In Step 3, it's critical the customer si=
gn the message with the private<br>
key of the refund address, so that the merchant can be confident the<br>
refund address is correct.<br></blockquote><div><br></div><div>Refund addre=
sses as specced currently are optional. For instance bitcoinj currently doe=
sn't use them and won't until HD wallets support is done.</div>
<div><br></div><div>Let's get some practical experience with what we=
9;ve got so far. We can evolve PaymentRequest/Payment/PaymentACK in the rig=
ht direction with backwards compatible upgrades, I am hoping.</div></div>
</div></div>
--001a11c2e60a063d4a04f12dd09d--
|
