* [Bitcoin-development] BIP70: PaymentACK semantics @ 2014-01-26 21:56 Andreas Schildbach 2014-01-27 14:54 ` Gavin Andresen 0 siblings, 1 reply; 22+ messages in thread From: Andreas Schildbach @ 2014-01-26 21:56 UTC (permalink / raw) To: bitcoin-development 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 a syntactically correct Payment message? Does it mean the Payment is valid? Does it mean the Payment is valid and confirmed? How long can we delay the ack until all conditions for payment are met? I assume its not a good idea to keep the HTTP (or Bluetooth, for that matter) connection open for an hour while waiting for a blockchain confirmation. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-26 21:56 [Bitcoin-development] BIP70: PaymentACK semantics Andreas Schildbach @ 2014-01-27 14:54 ` Gavin Andresen 2014-01-27 15:20 ` Andreas Schildbach 2014-01-27 15:52 ` Mike Hearn 0 siblings, 2 replies; 22+ messages in thread From: Gavin Andresen @ 2014-01-27 14:54 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1572 bytes --] On Sun, Jan 26, 2014 at 4:56 PM, Andreas Schildbach <andreas@schildbach•de>wrote: > 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 a syntactically correct Payment message? > Does it mean the Payment is valid? > Does it mean the Payment is valid and confirmed? > How long can we delay the ack until all conditions for payment are met? > I assume its not a good idea to keep the HTTP (or Bluetooth, for that > matter) connection open for an hour while waiting for a blockchain > confirmation. > 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 a PaymentACK with a message saying that there is a problem should be the response. Waiting until confirmed is definitely not the right thing to do, but waiting a few seconds to detect a 0-confirmation double-spend attempt before sending back an ACK is fine. The BIP is intentionally vague on how long it might take to get an ACK, but, again, the intent is to give the customer reassurance that their payment was received and is being processed, whatever "processed" means (order sent to shipping for fulfillment, or awaiting 11 confirmations, or "your burger is paid for you can leave the restaurant and we won't chase after you"). -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 2161 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 14:54 ` Gavin Andresen @ 2014-01-27 15:20 ` Andreas Schildbach 2014-01-27 15:52 ` Mike Hearn 1 sibling, 0 replies; 22+ messages in thread From: Andreas Schildbach @ 2014-01-27 15:20 UTC (permalink / raw) To: bitcoin-development 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 a PaymentACK with a message saying > that there is a problem should be the response. Thanks for the clarification. So I am *always* supposed to reply with an ack. I was assuming that if I actually send a nack, I would just close the connection without sending an ack. Maybe that should be mentioned in the spec explicitly. I must admit that I think the name of the message is misleading -- PaymentResponse would make this clearer. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 14:54 ` Gavin Andresen 2014-01-27 15:20 ` Andreas Schildbach @ 2014-01-27 15:52 ` Mike Hearn 2014-01-27 22:03 ` Kevin Greene 1 sibling, 1 reply; 22+ messages in thread From: Mike Hearn @ 2014-01-27 15:52 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 225 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 254 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 15:52 ` Mike Hearn @ 2014-01-27 22:03 ` Kevin Greene 2014-01-27 22:17 ` Pieter Wuille 0 siblings, 1 reply; 22+ messages in thread From: Kevin Greene @ 2014-01-27 22:03 UTC (permalink / raw) To: Mike Hearn; +Cc: Andreas Schildbach, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1081 bytes --] +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 <mike@plan99•net> wrote: > 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. > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 1884 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 22:03 ` Kevin Greene @ 2014-01-27 22:17 ` Pieter Wuille 2014-01-27 22:39 ` Kevin Greene 2014-01-30 14:51 ` Jeff Garzik 0 siblings, 2 replies; 22+ messages in thread From: Pieter Wuille @ 2014-01-27 22:17 UTC (permalink / raw) To: Kevin Greene; +Cc: Bitcoin Dev, Andreas Schildbach On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@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 ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 22:17 ` Pieter Wuille @ 2014-01-27 22:39 ` Kevin Greene 2014-01-28 11:42 ` Mike Hearn 2014-01-30 14:51 ` Jeff Garzik 1 sibling, 1 reply; 22+ messages in thread From: Kevin Greene @ 2014-01-27 22:39 UTC (permalink / raw) To: Pieter Wuille; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1253 bytes --] >> 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@gmail•com>wrote: > On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@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 > [-- Attachment #2: Type: text/html, Size: 2877 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 22:39 ` Kevin Greene @ 2014-01-28 11:42 ` Mike Hearn 2014-01-28 12:53 ` Gavin Andresen 0 siblings, 1 reply; 22+ messages in thread From: Mike Hearn @ 2014-01-28 11:42 UTC (permalink / raw) To: Kevin Greene; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1627 bytes --] 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@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@gmail•com>wrote: > >> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@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 >> > > [-- Attachment #2: Type: text/html, Size: 3616 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 11:42 ` Mike Hearn @ 2014-01-28 12:53 ` Gavin Andresen 2014-01-28 13:09 ` Pieter Wuille ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Gavin Andresen @ 2014-01-28 12:53 UTC (permalink / raw) To: Mike Hearn; +Cc: Andreas Schildbach, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1239 bytes --] On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@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 think. > If the wallet software is doing automatic CoinJoin (for example), then typically one or several of the other participants will broadcast the transaction as soon as it is complete. If the spec said that wallets must not broadcast until they receive a PaymentACK (if a payment_url is specified), then you'd have to violate the spec to do CoinJoin. 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? if you eventually unlock the probably-not-quite-spent-yet inputs, should you double-spend them to yourself just in case the merchant eventually gets around to broadcasting the transaction, or should you just unlock them and squirrel away the failed Payment so if the merchant does eventually broadcast you have a record of why the coins were spent). -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 1651 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 12:53 ` Gavin Andresen @ 2014-01-28 13:09 ` Pieter Wuille 2014-01-28 13:24 ` Mike Hearn 2014-01-28 17:23 ` Peter Todd 2 siblings, 0 replies; 22+ messages in thread From: Pieter Wuille @ 2014-01-28 13:09 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Andreas Schildbach On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen <gavinandresen@gmail•com> wrote: > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@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 think. > > > If the wallet software is doing automatic CoinJoin (for example), then > typically one or several of the other participants will broadcast the > transaction as soon as it is complete. > > If the spec said that wallets must not broadcast until they receive a > PaymentACK (if a payment_url is specified), then you'd have to violate the > spec to do CoinJoin. You cannot prevent transactions from being broadcasted, but an ACK can still mean "You're now relieved of the responsibility of getting the transaction confirmed". That's independent from being allowed to broadcast it. > 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? if you eventually > unlock the probably-not-quite-spent-yet inputs, should you double-spend them > to yourself just in case the merchant eventually gets around to broadcasting > the transaction, or should you just unlock them and squirrel away the failed > Payment so if the merchant does eventually broadcast you have a record of > why the coins were spent). If a payment_url is unavailable, you should imho retry. If you broadcasted, and the payment_url is unavailable, you should *certainly* retry. Otherwise the recipient cannot rely on receiving memo and refund address, which would imho make these fields completely useless. I still like suggesting not broadcasting if a payment_uri to minimize that risk further, but as you say - there are enough cases where you cannot enforce that anyway. -- Pieter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 12:53 ` Gavin Andresen 2014-01-28 13:09 ` Pieter Wuille @ 2014-01-28 13:24 ` Mike Hearn 2014-01-28 17:23 ` Peter Todd 2 siblings, 0 replies; 22+ messages in thread From: Mike Hearn @ 2014-01-28 13:24 UTC (permalink / raw) To: Gavin Andresen; +Cc: Andreas Schildbach, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 844 bytes --] > > 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 they don't succeed, then the transaction is just never committed to the wallet. Doesn't seem like a big deal. Payment submission is online, interactive. If it fails, you keep the coins. This seems simple and straightforward. If someone really wanted to do a real-time coinjoin, they can build the transaction together and submit it via payment_url, and broadcast as well. If the merchant has an issue with the payment for some reason (e.g. request is expired or the tx is non-standard), well, you'll have to sort it out with them manually. [-- Attachment #2: Type: text/html, Size: 1195 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 12:53 ` Gavin Andresen 2014-01-28 13:09 ` Pieter Wuille 2014-01-28 13:24 ` Mike Hearn @ 2014-01-28 17:23 ` Peter Todd 2014-01-28 17:33 ` Mike Hearn 2 siblings, 1 reply; 22+ messages in thread From: Peter Todd @ 2014-01-28 17:23 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 2288 bytes --] On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote: > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@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 think. > > > > If the wallet software is doing automatic CoinJoin (for example), then > typically one or several of the other participants will broadcast the > transaction as soon as it is complete. > > If the spec said that wallets must not broadcast until they receive a > PaymentACK (if a payment_url is specified), then you'd have to violate the > spec to do CoinJoin. > > 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? if you eventually > unlock the probably-not-quite-spent-yet inputs, should you double-spend > them to yourself just in case the merchant eventually gets around to > broadcasting the transaction, or should you just unlock them and squirrel > away the failed Payment so if the merchant does eventually broadcast you > have a record of why the coins were spent). Also users don't have infinite unspent txouts in their wallets - if they need to make two payments in a row and run out their wallet software is (currently) going to spend the change txout and either be forced to broadcast both transactions anyway, or the second payment-protocol-using recipient will do so on their behalf. (in the future they might also do a replacement tx replacing the first with a single tx paying both to save on fees, again with the same problem) Anyway what you want is payment atomicity: the customer losing control of the funds must be atomic with respect to the payment going through. From that point of view it's unfortunate that Payment message contains refund_to, memo, etc. That information should have been provided to the merchant prior to them providing the list of addresses to pay. -- 'peter'[:-1]@petertodd.org 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 17:23 ` Peter Todd @ 2014-01-28 17:33 ` Mike Hearn 2014-01-28 21:12 ` Peter Todd 0 siblings, 1 reply; 22+ messages in thread From: Mike Hearn @ 2014-01-28 17:33 UTC (permalink / raw) To: Peter Todd; +Cc: Andreas Schildbach, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3268 bytes --] 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 dust tx or one that's invalid/too low fee/etc. So I think we have a bit of time to figure this out. But yes - once you broadcast, you probably accept that there might be a more painful path to resolve issues if something goes wrong, I guess. Right now BitPay has a support system where you can file a ticket if you pay the bitcoins and they don't recognise it or the tx never confirms or whatever. It's grotty manual work but they do it. Not broadcasting unless you "have" to seems like an optimisation that can reduce pain without much additional complexity. On Tue, Jan 28, 2014 at 6:23 PM, Peter Todd <pete@petertodd•org> wrote: > On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote: > > On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn <mike@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 think. > > > > > > > If the wallet software is doing automatic CoinJoin (for example), then > > typically one or several of the other participants will broadcast the > > transaction as soon as it is complete. > > > > If the spec said that wallets must not broadcast until they receive a > > PaymentACK (if a payment_url is specified), then you'd have to violate > the > > spec to do CoinJoin. > > > > 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? if you eventually > > unlock the probably-not-quite-spent-yet inputs, should you double-spend > > them to yourself just in case the merchant eventually gets around to > > broadcasting the transaction, or should you just unlock them and squirrel > > away the failed Payment so if the merchant does eventually broadcast you > > have a record of why the coins were spent). > > Also users don't have infinite unspent txouts in their wallets - if they > need to make two payments in a row and run out their wallet software is > (currently) going to spend the change txout and either be forced to > broadcast both transactions anyway, or the second payment-protocol-using > recipient will do so on their behalf. (in the future they might also do > a replacement tx replacing the first with a single tx paying both to > save on fees, again with the same problem) > > Anyway what you want is payment atomicity: the customer losing control > of the funds must be atomic with respect to the payment going through. > From that point of view it's unfortunate that Payment message contains > refund_to, memo, etc. That information should have been provided to the > merchant prior to them providing the list of addresses to pay. > > -- > 'peter'[:-1]@petertodd.org > 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 > [-- Attachment #2: Type: text/html, Size: 4068 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-28 17:33 ` Mike Hearn @ 2014-01-28 21:12 ` Peter Todd 0 siblings, 0 replies; 22+ messages in thread From: Peter Todd @ 2014-01-28 21:12 UTC (permalink / raw) To: Mike Hearn; +Cc: Andreas Schildbach, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2313 bytes --] 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 imperfect fungibility of bitcoins, e.g. you try and pay with a huge > dust tx or one that's invalid/too low fee/etc. > > So I think we have a bit of time to figure this out. But yes - once you > broadcast, you probably accept that there might be a more painful path to > resolve issues if something goes wrong, I guess. Right now BitPay has a > support system where you can file a ticket if you pay the bitcoins and they > don't recognise it or the tx never confirms or whatever. It's grotty manual > work but they do it. Not broadcasting unless you "have" to seems like an > optimisation that can reduce pain without much additional complexity. That's the reason you use a model where things happen atomicly: the funds either can or can't be transferred, so if the merchant screws up due to a server failure at worst the wallet can always send the original, signed, payment request and transaction details proving to the merchant that they agreed. Since the asked for txouts exist in the blockchain they must either refund the money, or ship the goods. Wallet software can handle that kind of worst-case failure by automatically sending the original payment request back to the merchant. At worst all customer support has to do is tell the customer "Sorry about that; we didn't get your payment. Please start your wallet up and hit the 'resend transaction' button in your wallet and we'll clear that right up." Keep in mind that we're probably going to see fraudsters figuring out ways to make payment servers fail. This means conversely that a customer calling up a merchant and saying "Hey! Something didn work but the wallet says I paid!" is going to be treated more suspiciously. By using atomic protocols the issue of did or didn't they pay becomes much more black and white, and failure resistant. That's exactly what we keep saying Bitcoin offers that PayPal doesn't. -- 'peter'[:-1]@petertodd.org 000000000000000085c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 685 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-27 22:17 ` Pieter Wuille 2014-01-27 22:39 ` Kevin Greene @ 2014-01-30 14:51 ` Jeff Garzik 2014-01-30 14:58 ` Pieter Wuille ` (2 more replies) 1 sibling, 3 replies; 22+ messages in thread From: Jeff Garzik @ 2014-01-30 14:51 UTC (permalink / raw) To: Pieter Wuille; +Cc: Andreas Schildbach, Bitcoin Dev On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote: > On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@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). Is this truly the intent? That the merchant/processor takes full responsibility for getting the TX confirmed? It is within the customer's economic incentive -- and right as a free person -- to work to get their transaction relayed to the network and confirmed in parallel with whatever the merchant is doing. BIP 70 states that the customer broadcasts the transaction, in addition to sending the Payment message. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 14:51 ` Jeff Garzik @ 2014-01-30 14:58 ` Pieter Wuille 2014-01-30 15:01 ` Mike Hearn 2014-01-30 15:06 ` Gavin Andresen 2 siblings, 0 replies; 22+ messages in thread From: Pieter Wuille @ 2014-01-30 14:58 UTC (permalink / raw) To: Jeff Garzik; +Cc: Andreas Schildbach, Bitcoin Dev On Thu, Jan 30, 2014 at 3:51 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > On Mon, Jan 27, 2014 at 5:17 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote: >> On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene <kgreenek@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). > > Is this truly the intent? That the merchant/processor takes full > responsibility for getting the TX confirmed? Confirmed is probably the wrong word. But IMHO (not how it's currently worded), the merchant should take that responsibility after delivering a PaymentACK. This means the client does not need to stay online anymore. More importantly, it removes the requirement for the P2P network to function as a reliable sender->receiver communication channel (and reduces it to a broadcast medium to get transactions to miners). -- Pieter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 14:51 ` Jeff Garzik 2014-01-30 14:58 ` Pieter Wuille @ 2014-01-30 15:01 ` Mike Hearn 2014-01-30 15:06 ` Gavin Andresen 2 siblings, 0 replies; 22+ messages in thread From: Mike Hearn @ 2014-01-30 15:01 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 521 bytes --] > > 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 a part of that as it'd make no sense for a merchant to give that assurance and decide they don't care about the money. But nothing stops the user broadcasting the tx as well, once the receiver has given that assurance. [-- Attachment #2: Type: text/html, Size: 844 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 14:51 ` Jeff Garzik 2014-01-30 14:58 ` Pieter Wuille 2014-01-30 15:01 ` Mike Hearn @ 2014-01-30 15:06 ` Gavin Andresen 2014-01-30 15:16 ` Pieter Wuille 2 siblings, 1 reply; 22+ messages in thread From: Gavin Andresen @ 2014-01-30 15:06 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 564 bytes --] On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik <jgarzik@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 broadcast the transaction as soon as possible or having it wait for the merchant to respond with a PaymentACK is better. But I think we should let wallets experiment with different ways of doing it, and see what works best in practice. -- -- Gavin Andresen [-- Attachment #2: Type: text/html, Size: 971 bytes --] ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 15:06 ` Gavin Andresen @ 2014-01-30 15:16 ` Pieter Wuille 2014-01-30 20:16 ` Jeremy Spilman 0 siblings, 1 reply; 22+ messages in thread From: Pieter Wuille @ 2014-01-30 15:16 UTC (permalink / raw) To: Gavin Andresen; +Cc: Bitcoin Dev, Andreas Schildbach On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen <gavinandresen@gmail•com> wrote: > On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik <jgarzik@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 broadcast the transaction as soon as > possible or having it wait for the merchant to respond with a PaymentACK is > better. But I think we should let wallets experiment with different ways of > doing it, and see what works best in practice. 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 alternative route for delivering that information to them *before* the transaction is made, as sending the transaction may result in the transfer of funds without knowing what to do with it (if their receive server is down at the right time) and potnetially no way to contact the sender. This makes these fields utterly useless. This is not a matter of letting wallets experiment with the best behaviour. This is removing the ability to rely on the payment protocol being bidirectional. I don't care whether wallets broadcast the transactions or not (they can experiment with that as they like). But we should take measures to prevent a transaction for being broadcast without the payment being delivered. One way is never broadcasting the transaction yourself. Another is retrying to send the payment if delivery fails. Here is what I would suggest to add to the specification: * If a payment_uri is specified, the client must attempt to send the payment there. * If a transaction is broadcast (which is permitted even if sending the payment fails), a client should make a reasonable attempt of delivering the payment (remembering, retrying, ...). * If a paymentACK has been received, the client is no longer responsible for broadcasting the transaction (but still may). -- Pieter ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 15:16 ` Pieter Wuille @ 2014-01-30 20:16 ` Jeremy Spilman 2014-01-31 4:16 ` Chuck 0 siblings, 1 reply; 22+ messages in thread From: Jeremy Spilman @ 2014-01-30 20:16 UTC (permalink / raw) To: Gavin Andresen, Pieter Wuille; +Cc: Bitcoin Dev, Andreas Schildbach Please note, responding to Pieter and Chuck concurrently. On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille <pieter.wuille@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 alternative route for delivering that information to them > *before* the transaction is made, as sending the transaction may > result in the transfer of funds without knowing what to do with it (if > their receive server is down at the right time) and potnetially no way > to contact the sender. This makes these fields utterly useless. > > This is not a matter of letting wallets experiment with the best > behaviour. This is removing the ability to rely on the payment > protocol being bidirectional. 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 be able to solve '1' without having to fully spec out behavior for 2. On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille <pieter.wuille@gmail•com> wrote: > I don't care whether wallets broadcast the transactions or not (they > can experiment with that as they like). But we should take measures to > prevent a transaction for being broadcast without the payment being > delivered. One way is never broadcasting the transaction yourself. > Another is retrying to send the payment if delivery fails. > > Here is what I would suggest to add to the specification: > * If a payment_uri is specified, the client must attempt to send the > payment there. > * If a transaction is broadcast (which is permitted even if sending > the payment fails), a client should make a reasonable attempt of > delivering the payment (remembering, retrying, ...). > * If a paymentACK has been received, the client is no longer > responsible for broadcasting the transaction (but still may). To reliably deliver refund/memo fields, we could; a) Send them as part of the initial request for the PaymentRequest/PaymentDetails b) Send them as a response to the PaymentRequest/PaymentDetails before the transaction is even formed and any unspent outputs are selected c) Send them as a response to the PaymentRequest/PaymentDetails with the UNsigned transaction, and then follow up with the signed transaction in a separate message. 'a' is problematic because while wallet software could easily append some data to the queryString, it doesn't work if the user is downloading then opening the PaymentRequest as a file. So 'a' is a no-go I think. 'b' is fine, if not overly chatty. The only thing committed is a refund address, which is a lot less problematic than committed unspent outputs. 'c' is nice because it lets the server preview the transaction (and ACK/NACK it with a memo of their own -- e.g. 'fee too low'?) without being able to broadcast it, so we know unspent outputs are not yet committed. But all of these require too many changes to the protocol for my liking. On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle•com> wrote: > 3. Customer builds a set of transactions and sends a new > PaymentApprovalRequest message which includes a refund address and the > unsigned transactions and their associated fully-signed transactionhash, > the whole message signed with the private key of the refund address. "Unsigned transactions and their associated fully-signed transaction hash" -- isn't that a fully signed transaction? In this case, it doesn't solve the core problem of the server being able to broadcast that transaction without ACKing. On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle•com> wrote: > In Step 3, it's critical the customer sign the message with the private > key of the refund address, so that the merchant can be confident the > refund address is correct. For merchant confidence that the address is correct, we can leave the transport security to the transport layer. For payer proving refund address was X after merchant sends a refund to Y, that's a different story. I don't think we want to *require* access to the refund address private key. For example, BIP32 public derivation may have just the pubkey available. Offline transaction signing is one thing, but offline PP message signing is too much. I think there are better ways to secure the refund address which can reuse existing code, and certainly the option should remain to send a plain refund address just relying on transport security and trusting the merchant. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-30 20:16 ` Jeremy Spilman @ 2014-01-31 4:16 ` Chuck 2014-01-31 16:21 ` Christophe Biocca 0 siblings, 1 reply; 22+ messages in thread From: Chuck @ 2014-01-31 4:16 UTC (permalink / raw) To: bitcoin-development, Jeremy Spilman, Pieter Wuille; +Cc: Andreas Schildbach 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 be able to solve '1' without having to fully spec out behavior > for 2. My original message was focused on #1. Not only #1, but ensuring the merchant can't act maliciously too. As far as #2 is concerned, I don't think it makes any difference - it's in both the customer and the merchant's best interest to have the transactions confirmed. > c) Send them as a response to the PaymentRequest/PaymentDetails with the > UNsigned transaction, and then follow up with the signed transaction in a > separate message. ... > On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle•com> > wrote: >> 3. Customer builds a set of transactions and sends a new >> PaymentApprovalRequest message which includes a refund address and the >> unsigned transactions and their associated fully-signed transactionhash, >> the whole message signed with the private key of the refund address. > "Unsigned transactions and their associated fully-signed transaction hash" > -- isn't that a fully signed transaction? In this case, it doesn't solve > the core problem of the server being able to broadcast that transaction > without ACKing. What I meant was (and maybe this was roundabout?): the customer includes the UNsigned transactions as well as the hashes (and only the hashes) of the fully signed transactions. The customer keeps the fully signed transactions private until the merchant ACKs the unsigned versions. If the merchant has the hash of the fully signed transaction, he can monitor the network for delivery of the signed transaction. It definitely complicates things, but it's nothing that can't be done. Cheers, Chuck ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [Bitcoin-development] BIP70: PaymentACK semantics 2014-01-31 4:16 ` Chuck @ 2014-01-31 16:21 ` Christophe Biocca 0 siblings, 0 replies; 22+ messages in thread From: Christophe Biocca @ 2014-01-31 16:21 UTC (permalink / raw) To: Chuck; +Cc: bitcoin-development 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 unsigned transactions before the payment is effectively irreversible. I can't come up with a situation where the combination of signed request and blockchain entry aren't enough evidence, yet where adding an ACK by the merchant of the unsigned transaction tips the balance the other way. If you know of such a possibility, I'd love to hear it, because we'd know what we're trying to fix. The only way I can see a malicious merchant exploiting wallet behaviour around PaymentACK is by accepting the Payment message, not broadcasting it, not returning an ACK, and hoping the wallet/user retries paying with a new, non-conflicting transaction. Then he can try milking multiple small payments out of the user before they realize what happened, and broadcast them all at once, stealing more funds than the user ever was willing to risk in the transaction. But this is trivial to guard against at the wallet level (by making every new payment conflict with all previous non-acked payments). The non-reliability of getting memo/refund fields is a separate problem, but it seems BitcoinJ's approach addresses that nicely. On Thu, Jan 30, 2014 at 11:16 PM, Chuck <chuck+bitcoindev@borboggle•com> wrote: > 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 be able to solve '1' without having to fully spec out behavior >> for 2. > My original message was focused on #1. Not only #1, but ensuring the > merchant can't act maliciously too. > > As far as #2 is concerned, I don't think it makes any difference - it's > in both the customer and the merchant's best interest to have the > transactions confirmed. > >> c) Send them as a response to the PaymentRequest/PaymentDetails with the >> UNsigned transaction, and then follow up with the signed transaction in a >> separate message. > ... >> On Wed, 29 Jan 2014 21:47:51 -0800, Chuck <chuck+bitcoindev@borboggle•com> >> wrote: >>> 3. Customer builds a set of transactions and sends a new >>> PaymentApprovalRequest message which includes a refund address and the >>> unsigned transactions and their associated fully-signed transactionhash, >>> the whole message signed with the private key of the refund address. >> "Unsigned transactions and their associated fully-signed transaction hash" >> -- isn't that a fully signed transaction? In this case, it doesn't solve >> the core problem of the server being able to broadcast that transaction >> without ACKing. > What I meant was (and maybe this was roundabout?): the customer includes > the UNsigned transactions as well as the hashes (and only the hashes) of > the fully signed transactions. The customer keeps the fully signed > transactions private until the merchant ACKs the unsigned versions. If > the merchant has the hash of the fully signed transaction, he can > monitor the network for delivery of the signed transaction. > > It definitely complicates things, but it's nothing that can't be done. > > Cheers, > > Chuck > > ------------------------------------------------------------------------------ > WatchGuard Dimension instantly turns raw network data into actionable > security intelligence. It gives you real-time visual feedback on key > security issues and trends. Skip the complicated setup - simply import > a virtual appliance and go from zero to informed in seconds. > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2014-01-31 16:22 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-26 21:56 [Bitcoin-development] BIP70: PaymentACK semantics Andreas Schildbach 2014-01-27 14:54 ` Gavin Andresen 2014-01-27 15:20 ` Andreas Schildbach 2014-01-27 15:52 ` Mike Hearn 2014-01-27 22:03 ` Kevin Greene 2014-01-27 22:17 ` Pieter Wuille 2014-01-27 22:39 ` Kevin Greene 2014-01-28 11:42 ` Mike Hearn 2014-01-28 12:53 ` Gavin Andresen 2014-01-28 13:09 ` Pieter Wuille 2014-01-28 13:24 ` Mike Hearn 2014-01-28 17:23 ` Peter Todd 2014-01-28 17:33 ` Mike Hearn 2014-01-28 21:12 ` Peter Todd 2014-01-30 14:51 ` Jeff Garzik 2014-01-30 14:58 ` Pieter Wuille 2014-01-30 15:01 ` Mike Hearn 2014-01-30 15:06 ` Gavin Andresen 2014-01-30 15:16 ` Pieter Wuille 2014-01-30 20:16 ` Jeremy Spilman 2014-01-31 4:16 ` Chuck 2014-01-31 16:21 ` Christophe Biocca
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox