Re: [Bitcoin-development] BIP70: PaymentACK semantics
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+bitcoin...@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+bitcoin...@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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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/ -- 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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. -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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.wui...@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+bitcoin...@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+bitcoin...@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. -- 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
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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+bitcoin...@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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 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.wui...@gmail.comwrote: 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 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 -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=123612991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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. -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 signature.asc Description: Digital signature -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 p...@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 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 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 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 85c725a905444d271c56fdee4e4ec7f27bdb2e777c872925 signature.asc Description: Digital signature -- 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=123612991iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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. -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
+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 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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 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 -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70: PaymentACK semantics
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.wui...@gmail.comwrote: 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 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 -- 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
