summaryrefslogtreecommitdiff
path: root/cb/9314dfcaed4bc8cb1991fb4027730a7cc929ff
blob: 15b49867aa9d720e1b0ce190cb9b6167ff701d39 (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
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WTVFi-00084P-JL
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Mar 2014 11:47:14 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.47 as permitted sender)
	client-ip=209.85.219.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f47.google.com; 
Received: from mail-oa0-f47.google.com ([209.85.219.47])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WTVFS-0004YV-J6
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Mar 2014 11:47:14 +0000
Received: by mail-oa0-f47.google.com with SMTP id i11so5893947oag.6
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 28 Mar 2014 04:46:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.183.24.161 with SMTP id ij1mr6469232obd.33.1396007213220;
	Fri, 28 Mar 2014 04:46:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 28 Mar 2014 04:46:53 -0700 (PDT)
In-Reply-To: <122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com>
References: <CANEZrP0AwR3WgHfwYWcrC9Z_MHPDwymWXAQwp7D8XZ+o2FsK8g@mail.gmail.com>
	<lh3m7i$v18$1@ger.gmane.org>
	<CA+s+GJCf9o6VEky=JXgrG8v39hyQtPz71yuftF_jyp0bX9WHsA@mail.gmail.com>
	<122FC5AD-2117-4CAF-817F-45B00F57D549@bitsofproof.com>
Date: Fri, 28 Mar 2014 12:46:53 +0100
X-Google-Sender-Auth: 3T4og6jRrLd89ezpHYFX8YtmEJs
Message-ID: <CANEZrP30UsWsBJ-pzb=LQP-MB+PDE0buRdRbuUiOJxANLF9cpw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Tamas Blummer <tamas@bitsofproof.com>
Content-Type: multipart/alternative; boundary=001a1134aa020c4d2204f5a9422c
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
	0.0 TIME_LIMIT_EXCEEDED    Exceeded time limit / deadline
X-Headers-End: 1WTVFS-0004YV-J6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
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:47:14 -0000

--001a1134aa020c4d2204f5a9422c
Content-Type: text/plain; charset=UTF-8

I don't want to manage a "business relationship" with every shop I buy
something from. That's way too much effort. There can certainly be cases
where a more complicated relationship is created by bootstrapping off
BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller
relationship seems like a good scope for BIP70 for now.


On Fri, Mar 28, 2014 at 12:45 PM, Tamas Blummer <tamas@bitsofproof.com>wrote:

> Yes, you begin to see that the payment protocol, as is has a too narrow
> scope of a web cart - customer, and does not even fit that.
>
> It is not about payment requests but about business relationships. We need
> a protocol that deals with that concept instead of individual requests,
> so we really get out of the hell of addresses. Business relationships are
> terminated by the parties at their own and not bey algorithms and timeouts.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 28.03.2014, at 12:38, Wladimir <laanwj@gmail.com> wrote:
>
>
> On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <
> andreas@schildbach.de> wrote:
>
>> I see the problem.
>>
>> 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're probably aiming for an expires field? How would you refund a
>> payment after expiry? Note its not your choice wether to refund a
>> payment -- it can be ordered by a court years after the payment happened.
>>
>
> Communication between the merchant and buyer would be needed in this case.
>
> I'd say that would be not unreasonable if something is to be refunded
> after a year or more. After all, people may have moved, bank accounts
> changed, even outside the bitcoin world.
>
> It should probably not be accepted to set a very low expiration time for
> the refund address, like <3 months, as it's as bad as not providing a
> refund address at all and brings back all the pre-BIP70 confusion.
>
> Wladimir
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a1134aa020c4d2204f5a9422c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t want to manage a &quot;business relationship&q=
uot; with every shop I buy something from. That&#39;s way too much effort. =
There can certainly be cases where a more complicated relationship is creat=
ed by bootstrapping off BIP70, perhaps with an extension, but nailing the o=
rdinary buyer-to-seller relationship seems like a good scope for BIP70 for =
now.<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri, Mar 2=
8, 2014 at 12:45 PM, Tamas Blummer <span dir=3D"ltr">&lt;<a href=3D"mailto:=
tamas@bitsofproof.com" target=3D"_blank">tamas@bitsofproof.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div>Yes=
, you begin to see that the payment protocol, as is has a too narrow scope =
of a web cart - customer, and does not even fit that.</div>
<div><br></div><div>It is not about payment requests but about business rel=
ationships. We need a protocol that deals with that concept instead of indi=
vidual requests,</div><div>so we really get out of the hell of addresses. B=
usiness relationships are terminated by the parties at their own and not be=
y algorithms and timeouts.</div>
<div><br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal=
;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:n=
ormal;text-transform:none;font-size:medium;white-space:normal;font-family:H=
elvetica;word-spacing:0px">
<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=
xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh=
t:normal;float:none;line-height:normal;text-transform:none;font-size:medium=
;white-space:normal;font-family:Helvetica;word-spacing:0px">Regards,</span>=
<br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text=
-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal=
;text-transform:none;font-size:medium;white-space:normal;font-family:Helvet=
ica;word-spacing:0px">
<br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text=
-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal=
;text-transform:none;font-size:medium;white-space:normal;font-family:Helvet=
ica;word-spacing:0px">
<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=
xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh=
t:normal;float:none;line-height:normal;text-transform:none;font-size:medium=
;white-space:normal;font-family:Helvetica;word-spacing:0px">Tamas Blummer</=
span><br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal=
;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:n=
ormal;text-transform:none;font-size:medium;white-space:normal;font-family:H=
elvetica;word-spacing:0px">
<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te=
xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh=
t:normal;float:none;line-height:normal;text-transform:none;font-size:medium=
;white-space:normal;font-family:Helvetica;word-spacing:0px"><a href=3D"http=
://bitsofproof.com" target=3D"_blank">http://bitsofproof.com</a></span>
</div>
<br><div><div><div class=3D"h5"><div>On 28.03.2014, at 12:38, Wladimir &lt;=
<a href=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>&=
gt; wrote:</div><br></div></div><blockquote type=3D"cite"><div><div class=
=3D"h5">
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach <span dir=3D"ltr">&lt;=
<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@schildba=
ch.de</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I see the problem.<br>
<br>
However, I don&#39;t see how PaymentDetails can be an answer. None of the<b=
r>
fields (other than outputs and network) can be known in advance (at the<br>
time of the initial payment).<br>
<br>
You&#39;re probably aiming for an expires field? How would you refund a<br>
payment after expiry? Note its not your choice wether to refund a<br>
payment -- it can be ordered by a court years after the payment happened.<b=
r></blockquote><div><br></div><div>Communication between the merchant and b=
uyer would be needed in this case.<br><br></div><div>I&#39;d say that would=
 be not unreasonable if something is to be refunded after a year or more. A=
fter all, people may have moved, bank accounts changed, even outside the bi=
tcoin world.<br>

<br></div><div>It should probably not be accepted to set a very low expirat=
ion time for the refund address, like &lt;3 months, as it&#39;s as bad as n=
ot providing a refund address at all and brings back all the pre-BIP70 conf=
usion.<br>

</div><div></div><div><br></div><div>Wladimir<br></div></div><br></div></di=
v></div></div><div class=3D"">
---------------------------------------------------------------------------=
---<br>_______________________________________________<br>Bitcoin-developme=
nt mailing list<br><a href=3D"mailto:Bitcoin-development@lists.sourceforge.=
net" target=3D"_blank">Bitcoin-development@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></div></blockquote></div><br></div><br>-------------------=
-----------------------------------------------------------<br>

<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></div></div>

--001a1134aa020c4d2204f5a9422c--