Subject: Re: [Bitcoin-development] BIP70: PaymentACK semantics

From: Mike Hearn <[email-masked]>
Date: Tue, 28 Jan 2014 12:42:58 +0100

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 <[email-masked]> 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 <[email-masked]>wrote:
>
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <[email-masked]>
>> 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
>>
>
>