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
|
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 1W8CXW-0002Sp-Sp
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 17:33:34 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.173 as permitted sender)
client-ip=209.85.214.173; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f173.google.com;
Received: from mail-ob0-f173.google.com ([209.85.214.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W8CXV-00009l-I9
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 17:33:34 +0000
Received: by mail-ob0-f173.google.com with SMTP id vb8so748026obc.32
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Jan 2014 09:33:28 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.2.42 with SMTP id 10mr593348obr.73.1390930408123; Tue,
28 Jan 2014 09:33:28 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Tue, 28 Jan 2014 09:33:28 -0800 (PST)
In-Reply-To: <20140128172349.GA14168@savin>
References: <lc409d$4mf$1@ger.gmane.org>
<CABsx9T1Y3sO6eS54wsj377BL4rGoghx1uDzD+SY3tTgc1PPbHg@mail.gmail.com>
<CANEZrP0ENhJJhba8Xwj_cVzNKGDUQriia_Q=JWTXpztb6ic8rg@mail.gmail.com>
<CAEY8wq4QEO1rtaNdjHXR6-b3Cgi7pfSWk7M8khVi0MHCiVOBzQ@mail.gmail.com>
<CAPg+sBgUNYqYm7d4Rv+f0rBa=nSuqwmZ6_REBS7M-+Wea+za0g@mail.gmail.com>
<CAEY8wq6n_27Y2N7fVw9uJkfiiYqi6JkTwO0q03_J7tUeBhdQYA@mail.gmail.com>
<CANEZrP0HVJ7Uzow1=4-20LnejURqO5uo16H43uhL=TtNfzhAxQ@mail.gmail.com>
<CABsx9T2ng9vGMmfFK95A1jBK-FotDL-fA1oOt-=zosCPaug-rQ@mail.gmail.com>
<20140128172349.GA14168@savin>
Date: Tue, 28 Jan 2014 18:33:28 +0100
X-Google-Sender-Auth: oXfzv-stLfKo3ItKrwhlt7MPjJE
Message-ID: <CANEZrP0TiZMzNei2R-cBHGLxF4ts5Pe1_U4V6iQFV7y+Eu_MAA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1134ad06e2347e04f10b3838
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: 1W8CXV-00009l-I9
Cc: Andreas Schildbach <andreas@schildbach.de>,
Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
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, 28 Jan 2014 17:33:35 -0000
--001a1134ad06e2347e04f10b3838
Content-Type: text/plain; charset=UTF-8
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
dust tx or one that's invalid/too low fee/etc.
So I think we have a bit of time to figure this out. But yes - once you
broadcast, you probably accept that there might be a more painful path to
resolve issues if something goes wrong, I guess. Right now BitPay has a
support system where you can file a ticket if you pay the bitcoins and they
don't recognise it or the tx never confirms or whatever. It's grotty manual
work but they do it. Not broadcasting unless you "have" to seems like an
optimisation that can reduce pain without much additional complexity.
On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <pete@petertodd.org> wrote:
> On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
> > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@plan99.net> wrote:
> >
> > > Yeah, that's the interpretation I think we should go with for now.
> There
> > > was a reason why this isn't specified and I forgot what it was - some
> > > inability to come to agreement on when to broadcast vs when to submit
> via
> > > HTTP, I think.
> > >
> >
> > If the wallet software is doing automatic CoinJoin (for example), then
> > typically one or several of the other participants will broadcast the
> > transaction as soon as it is complete.
> >
> > If the spec said that wallets must not broadcast until they receive a
> > PaymentACK (if a payment_url is specified), then you'd have to violate
> the
> > spec to do CoinJoin.
> >
> > And even if you don't care about CoinJoin, not broadcasting the
> transaction
> > as soon as the inputs are signed adds implementation complexity (should
> you
> > retry if payment_url is unavailable? how many times? if you eventually
> > unlock the probably-not-quite-spent-yet inputs, should you double-spend
> > them to yourself just in case the merchant eventually gets around to
> > broadcasting the transaction, or should you just unlock them and squirrel
> > away the failed Payment so if the merchant does eventually broadcast you
> > have a record of why the coins were spent).
>
> Also users don't have infinite unspent txouts in their wallets - if they
> need to make two payments in a row and run out their wallet software is
> (currently) going to spend the change txout and either be forced to
> broadcast both transactions anyway, or the second payment-protocol-using
> recipient will do so on their behalf. (in the future they might also do
> a replacement tx replacing the first with a single tx paying both to
> save on fees, again with the same problem)
>
> Anyway what you want is payment atomicity: the customer losing control
> of the funds must be atomic with respect to the payment going through.
> From that point of view it's unfortunate that Payment message contains
> refund_to, memo, etc. That information should have been provided to the
> merchant prior to them providing the list of addresses to pay.
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925
>
--001a1134ad06e2347e04f10b3838
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In practice this should only be an issue if a payment is s=
ubmitted and fails, which should be rare. Barring internal server errors an=
d screwups on the merchants side, the only reasons for a rejection at submi=
t time would be the imperfect fungibility of bitcoins, e.g. you try and pay=
with a huge dust tx or one that's invalid/too low fee/etc.<div>
<br></div><div>So I think we have a bit of time to figure this out. But yes=
- once you broadcast, you probably accept that there might be a more painf=
ul path to resolve issues if something goes wrong, I guess. Right now BitPa=
y has a support system where you can file a ticket if you pay the bitcoins =
and they don't recognise it or the tx never confirms or whatever. It=
9;s grotty manual work but they do it. Not broadcasting unless you "ha=
ve" to seems like an optimisation that can reduce pain without much ad=
ditional complexity.</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <span dir=3D"ltr"><<=
a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</=
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"><div class=3D"HOEnZb"><div class=3D"h5">On T=
ue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:<br>
> On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <<a href=3D"mailto:mike=
@plan99.net">mike@plan99.net</a>> wrote:<br>
><br>
> > Yeah, that's the interpretation I think we should go with for=
now. There<br>
> > was a reason why this isn't specified and I forgot what it wa=
s - some<br>
> > inability to come to agreement on when to broadcast vs when to su=
bmit via<br>
> > HTTP, I think.<br>
> ><br>
><br>
> If the wallet software is doing automatic CoinJoin (for example), then=
<br>
> typically one or several of the other participants will broadcast the<=
br>
> transaction as soon as it is complete.<br>
><br>
> If the spec said that wallets must not broadcast until they receive a<=
br>
> PaymentACK (if a payment_url is specified), then you'd have to vio=
late the<br>
> spec to do CoinJoin.<br>
><br>
> And even if you don't care about CoinJoin, not broadcasting the tr=
ansaction<br>
> as soon as the inputs are signed adds implementation complexity (shoul=
d you<br>
> retry if payment_url is unavailable? how many times? if you eventually=
<br>
> unlock the probably-not-quite-spent-yet inputs, should you double-spen=
d<br>
> them to yourself just in case the merchant eventually gets around to<b=
r>
> broadcasting the transaction, or should you just unlock them and squir=
rel<br>
> away the failed Payment so if the merchant does eventually broadcast y=
ou<br>
> have a record of why the coins were spent).<br>
<br>
</div></div>Also users don't have infinite unspent txouts in their wall=
ets - if they<br>
need to make two payments in a row and run out their wallet software is<br>
(currently) going to spend the change txout and either be forced to<br>
broadcast both transactions anyway, or the second payment-protocol-using<br=
>
recipient will do so on their behalf. (in the future they might also do<br>
a replacement tx replacing the first with a single tx paying both to<br>
save on fees, again with the same problem)<br>
<br>
Anyway what you want is payment atomicity: the customer losing control<br>
of the funds must be atomic with respect to the payment going through.<br>
From that point of view it's unfortunate that Payment message contains<=
br>
refund_to, memo, etc. That information should have been provided to the<br>
merchant prior to them providing the list of addresses to pay.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925<br>
</font></span></blockquote></div><br></div>
--001a1134ad06e2347e04f10b3838--
|
