>
> If you sent the Payment message and the server goes silent after receiving
> it, you retry to delivery. However, the merchant can broadcast the
> transactions and force them into your wallet anyway. You could, quite
> likely, pay and never get an ACK.
>
No retries. If there's a timeout the wa
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote:
> On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> > On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> >> With the way it works in bitcoinj, the tx is only committed to the wallet
> >> if
> >> the server accepts the Payment message and ACKs i
On 1/30/2014 7:02 PM, Pieter Wuille wrote:
> On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
>> With the way it works in bitcoinj, the tx is only committed to the wallet if
>> the server accepts the Payment message and ACKs it. So the tx would not be
>> retried if there's a failure submitting
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn wrote:
> With the way it works in bitcoinj, the tx is only committed to the wallet if
> the server accepts the Payment message and ACKs it. So the tx would not be
> retried if there's a failure submitting or some kind of internal server
> error, and the
With the way it works in bitcoinj, the tx is only committed to the wallet
if the server accepts the Payment message and ACKs it. So the tx would not
be retried if there's a failure submitting or some kind of internal server
error, and the UI would show that the payment failed. That seems
straightfo
On Thu, Jan 30, 2014 at 12:15 PM, Chuck wrote:
> Hi Mike. Thanks for replying.
>
> On 1/30/2014 5:49 PM, Mike Hearn wrote:
>> Both Bitcoin Core and bitcoinj are about to ship with the protocol
>> as-is, so any changes from this point on have to be backwards compatible.
> Then I think it's critica
On 1/30/2014 6:31 PM, Mike Hearn wrote:
> The arbitrator would presumably have some rules about what is or isn't
> an acceptable form of payment.
Do you think this puts unnecessary trust into a third party? If the
merchant instead signed and agreed to the unsigned transactions before
they were
On Thu, Jan 30, 2014 at 12:15 PM, Chuck wrote:
> In arbitration the merchant could argue the transactions seen on the
> network were insufficient.
>
The arbitrator would presumably have some rules about what is or isn't an
acceptable form of payment.
HTTP has response codes for submission of the
Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
> Both Bitcoin Core and bitcoinj are about to ship with the protocol
> as-is, so any changes from this point on have to be backwards compatible.
Then I think it's critically important to talk about failure situations
now, rat
Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck wrote:
> I presume the receipt R=(PaymentRequest,[transactions]) would suffice.
>
That's all you need to
I spoke briefly with Peter (sipa). He recommend I forward this post to
the mailing list for further discussion.
My apologies if this has been discussed before, but I was curious about
some things re BIP70 message delivery. In particular, I don't clearly
see the value of the PaymentACK message.
11 matches
Mail list logo
