Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-01-28 📝 Original message:Yeah, that's the ...

📅 Original date posted:2014-01-28
📝 Original message: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 at 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 at gmail.com>wrote:
>
>> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140128/9ccedef8/attachment.html>;