Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-31 Thread Christophe Biocca
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Jeff Garzik
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Gavin Andresen
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Pieter Wuille
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Pieter Wuille
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Jeremy Spilman
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Chuck
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Gavin Andresen
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Pieter Wuille
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Peter Todd
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Mike Hearn
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Peter Todd
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Mike Hearn
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.

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Andreas Schildbach
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Gavin Andresen
On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach andr...@schildbach.dewrote: The BIP70 is very brief on what a PaymentACK is supposed to mean. Quote: it [PaymentACK] is sent from the merchant's server to the bitcoin wallet in response to a Payment message Does it simply mean we received

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Kevin Greene
+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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Pieter Wuille
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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Kevin Greene
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