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
|
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 1WTV0g-00077r-6j
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:31:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.41 as permitted sender)
client-ip=209.85.219.41; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f41.google.com;
Received: from mail-oa0-f41.google.com ([209.85.219.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTV0f-00041H-53
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Mar 2014 11:31:42 +0000
Received: by mail-oa0-f41.google.com with SMTP id j17so5966041oag.28
for <bitcoin-development@lists.sourceforge.net>;
Fri, 28 Mar 2014 04:31:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.93.168 with SMTP id cv8mr6469150oeb.21.1396006295797;
Fri, 28 Mar 2014 04:31:35 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 04:31:35 -0700 (PDT)
In-Reply-To: <lh3m7i$v18$1@ger.gmane.org>
References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
<lh3m7i$v18$1@ger.gmane.org>
Date: Fri, 28 Mar 2014 12:31:35 +0100
X-Google-Sender-Auth: UTxozhWbc4E6UPyFadT4ONs9GXM
Message-ID: <CANEZrP3zBFs=JpJi6eazTvrTaRX6XCJLu-zrraE6bezYW7b9pQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=047d7b33d3c05d872704f5a90ba7
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: 1WTV0f-00041H-53
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 70 refund field
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: Fri, 28 Mar 2014 11:31:42 -0000
--047d7b33d3c05d872704f5a90ba7
Content-Type: text/plain; charset=UTF-8
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
<andreas@schildbach.de>wrote:
> However, I don't see how PaymentDetails can be an answer. None of the
> fields (other than outputs and network) can be known in advance (at the
> time of the initial payment).
>
You don't need all the fields indeed, but they're mostly optional (except
time). So for the refund you'd fill out:
outputs (same as today)
time
expiry_time
You're probably aiming for an expires field? How would you refund a
> payment after expiry?
>
It'd have to be ad-hoc at that point. OK, you don't get the nice UI that
the refund field provides. Oh well. It should be rare to get refunds very
very late after the purchase.
> Btw. another problem is that the refund address is currently unprotected.
>
Yes indeed as is the rest of the Payment structure. We talked about signing
it with one of the keys that's signing the Bitcoin transaction as well. But
it seems like a bit overkill. Usually it'll be submitted over HTTPS or a
(secured!) Bluetooth channel though so tampering with it should not be
possible.
However this does raise the question of whether a refund should be a full
blown PaymentRequest with optional PKI signing. Normally, I think, a seller
does not know or care about the identity of a buyer for refunds, outside of
their own tracking system.
--047d7b33d3c05d872704f5a90ba7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <span dir=3D"ltr"><<a h=
ref=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildbach.d=
e</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">However, I don't see how PaymentDetails =
can be an answer. None of the<br>
fields (other than outputs and network) can be known in advance (at the<br>
time of the initial payment).<br></blockquote><div><br></div><div>You don&#=
39;t need all the fields indeed, but they're mostly optional (except ti=
me). So for the refund you'd fill out:</div><div><br></div><div>outputs=
(same as today)</div>
<div>time</div><div>expiry_time</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">You're probably aiming for an expires field? How would you refu=
nd a<br>
payment after expiry?<br></blockquote><div><br></div><div>It'd have to =
be ad-hoc at that point. OK, you don't get the nice UI that the refund =
field provides. Oh well. It should be rare to get refunds very very late af=
ter the purchase.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Btw. another problem is tha=
t the refund address is currently unprotected.<br></blockquote><div><br></d=
iv><div>
Yes indeed as is the rest of the Payment structure. We talked about signing=
it with one of the keys that's signing the Bitcoin transaction as well=
. But it seems like a bit overkill. Usually it'll be submitted over HTT=
PS or a (secured!) Bluetooth channel though so tampering with it should not=
be possible.</div>
<div><br></div><div>However this does raise the question of whether a refun=
d should be a full blown PaymentRequest with optional PKI signing. Normally=
, I think, a seller does not know or care about the identity of a buyer for=
refunds, outside of their own tracking system.</div>
</div></div></div>
--047d7b33d3c05d872704f5a90ba7--
|
