The merchant can always act maliciously by simply not delivering the
goods. The only recourse the payment protocol provides at that point
is that you have proof the merchant is acting maliciously (or at the
very least his payment system is broken).
Your scheme just adds an ACK of the specific
On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@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
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumably
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote:
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
The intent is to give the customer a great experience. We could talk for
months about whether having the wallet
On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote:
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
The intent is to give the
On Thu, Jan 30, 2014 at 3:51 PM, Jeff Garzik jgar...@bitpay.com wrote:
On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote:
Should the wallet broadcast the transaction to the bitcoin network
Please note, responding to Pieter and Chuck concurrently.
On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille
pieter.wui...@gmail.com wrote:
Currently, with the specification and implementation in Bitcoin Core,
if a merchant wants to use the refund or memo feature, they need to
provide an
On 1/31/2014 3:16 AM, Jeremy Spilman wrote:
I think we want to separate the two issues;
1) Reliably getting refund/memo fields to the merchant/payee
2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and
if/when they should be [double]-spent to clear them
We should
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
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
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
On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen gavinandre...@gmail.com wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
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
And even if you don't care about CoinJoin, not broadcasting the
transaction as soon as the inputs are signed adds implementation complexity
(should you retry if payment_url is unavailable? how many times?
I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
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
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the imperfect fungibility of bitcoins, e.g. you try and pay with a huge
On Tue, Jan 28, 2014 at 06:33:28PM +0100, Mike Hearn wrote:
In practice this should only be an issue if a payment is submitted and
fails, which should be rare. Barring internal server errors and screwups on
the merchants side, the only reasons for a rejection at submit time would
be the
At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.
On 01/27/2014 03:54 PM, Gavin Andresen wrote:
The purpose of PaymentACK is to give the customer reassurance that their
payment request has been received and will be processed (or not).
If it is syntactically incorrect or invalid in a way that the payment
processor can detect right away then
+1 for an error field.
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?
On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn m...@plan99.net wrote:
At the moment there's no way to distinguish between a
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@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
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
20 matches
Mail list logo
