Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.169 as permitted sender)
	client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f169.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CAEY8wq6n_27Y2N7fVw9uJkfiiYqi6JkTwO0q03_J7tUeBhdQYA@mail.gmail.com>
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>
Date: Tue, 28 Jan 2014 12:42:58 +0100
Message-ID: <CANEZrP0HVJ7Uzow1=4-20LnejURqO5uo16H43uhL=TtNfzhAxQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Kevin Greene <kgreenek@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b5d49ce71e2ae04f106539b
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics
Precedence: list

--047d7b5d49ce71e2ae04f106539b
Content-Type: text/plain; charset=UTF-8

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.




On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene <kgreenek@gmail.com> wrote:

> >> Should the wallet broadcast the transaction to the bitcoin network when
> it
> >> receives an ACK, or always assume that the merchant server will do that?
> >
> > In my opinion, that should be the primary meaning of receiving an ACK:
> > acknowledgement that the receiver takes responsibility for getting the
> > transaction confirmed (to the extent possible, of course).
>
> Ok, so if there is no
> payment
> _url specified in the PaymentRequest, then the wallet is responsible for
> broadcasting
> the transaction to the bitcoin network
> .
> Otherwise, the wallet should
> rely on the merchant server to broadcast.
>
>
> On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
>
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@gmail.com>
>> wrote:
>> > +1 for an error field.
>>
>> Agree, I think we need a way for client applications to interpret the
>> response.
>>
>> > Should the wallet broadcast the transaction to the bitcoin network when
>> it
>> > receives an ACK, or always assume that the merchant server will do that?
>>
>> In my opinion, that should be the primary meaning of receiving an ACK:
>> acknowledgement that the receiver takes responsibility for getting the
>> transaction confirmed (to the extent possible, of course).
>
>
>>
>> --
>> Pieter
>>
>
>

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

<div dir=3D"ltr">Yeah, that&#39;s the interpretation I think we should go w=
ith for now. There was a reason why this isn&#39;t specified and I forgot w=
hat it was - some inability to come to agreement on when to broadcast vs wh=
en to submit via HTTP, I think.<div>
<br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div clas=
s=3D"gmail_quote">On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene <span dir=
=3D"ltr">&lt;<a href=3D"mailto:kgreenek@gmail.com" target=3D"_blank">kgreen=
ek@gmail.com</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"><div dir=3D"ltr"><div class=3D"im"><div clas=
s=3D"gmail_default"><div><font color=3D"#000000">&gt;&gt; Should the wallet=
 broadcast the transaction to the bitcoin network when it<br>
&gt;&gt; receives an ACK, or always assume that the merchant server will do=
 that?<br>



&gt;</font></div><span style=3D"color:rgb(34,34,34)">&gt; In my opinion, th=
at should be the primary meaning of receiving an ACK:</span><br style=3D"co=
lor:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">&gt; acknowledgement=
 that the receiver takes responsibility for getting the</span><br style=3D"=
color:rgb(34,34,34)">




<span style=3D"color:rgb(34,34,34)">&gt; transaction confirmed (to the exte=
nt possible, of course).</span><br></div><div class=3D"gmail_extra"><br></d=
iv></div><div class=3D"gmail_extra"><span style=3D"color:rgb(51,102,102)">O=
k, so if there is no <div class=3D"gmail_default" style=3D"color:rgb(51,102=
,102);display:inline">




payment</div>_url specified in the PaymentRequest, then the wallet is respo=
nsible for broadcasting<div class=3D"im"><div class=3D"gmail_default" style=
=3D"color:rgb(51,102,102);display:inline"> the transaction to the bitcoin n=
etwork</div>
</div></span><span style=3D"color:rgb(51,102,102)">.<div class=3D"gmail_def=
ault" style=3D"color:rgb(51,102,102);display:inline">


 </div>Otherwise, the wallet should </span><div class=3D"gmail_default" sty=
le=3D"color:rgb(51,102,102);display:inline">
rely on the merchant server to broadcast.</div></div><div><div class=3D"h5"=
><div class=3D"gmail_extra"><span style=3D"color:rgb(51,102,102)"></span></=
div><div class=3D"gmail_extra"><font color=3D"#336666"><br></font><br><div =
class=3D"gmail_quote">
On Mon, Jan 27, 2014 at 2:17 PM, Pieter Wuille <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.=
com</a>&gt;</span> wrote:<br>



<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene &lt;<a=
 href=3D"mailto:kgreenek@gmail.com" target=3D"_blank">kgreenek@gmail.com</a=
>&gt; wrote:<br>





&gt; +1 for an error field.<br>
<br>
</div>Agree, I think we need a way for client applications to interpret the=
 response.<br>
<div><br>
&gt; Should the wallet broadcast the transaction to the bitcoin network whe=
n it<br>
&gt; receives an ACK, or always assume that the merchant server will do tha=
t?<br>
<br>
</div>In my opinion, that should be the primary meaning of receiving an ACK=
:<br>
acknowledgement that the receiver takes responsibility for getting the<br>
transaction confirmed (to the extent possible, of course).</blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">





<span><font color=3D"#888888"><br>
<br>
--<br>
Pieter<br>
</font></span></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>

--047d7b5d49ce71e2ae04f106539b--