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 chuck+bitcoin...@borboggle.comwrote:
I presume the receipt R=(PaymentRequest,[transactions]) would
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,
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.comwrote:
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
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 chuck+bitcoin...@borboggle.com 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.
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
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net 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
On 1/30/2014 7:02 PM, Pieter Wuille wrote:
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net 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
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 m...@plan99.net wrote:
With the way it works in bitcoinj, the tx is only committed to the wallet
if
the server accepts the Payment message and
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 wallet
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
11 matches
Mail list logo
