Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Just a small update. I merged the code to my bitcoinj-0.11 branch and put up binary .apk files for experimentation. Just make sure to tick BIP70 for tap-to-pay/scan-to-pay in the labs settings. Source: https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on a branch of Bitcoin Wallet. It is using bitcoinj 0.11 (not released). https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol -- 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 message delivery reliability
Hi Chuck, Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is, so any changes from this point on have to be backwards compatible. On Thu, Jan 30, 2014 at 6:47 AM, Chuck chuck+bitcoin...@borboggle.comwrote: I presume the receipt R=(PaymentRequest,[transactions]) would suffice. That's all you need to prove payment, yes. In the well-behaved case, I presume the point is to help the merchant associate some arbitrary data with the purchase as well as provide a refunding address for the customer. That's right (+memo). And to provide an additional hook for future features, like recurring billing, ECDH key agreements etc. 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. Refund addresses as specced currently are optional. For instance bitcoinj currently doesn't use them and won't until HD wallets support is done. Let's get some practical experience with what we've got so far. We can evolve PaymentRequest/Payment/PaymentACK in the right direction with backwards compatible upgrades, I am hoping. -- 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] Payment Protocol for Face-to-face Payments
Although it should be noted that these binaries don't yet do URI support so you can't scan a bitcoin URI with r= in it and see the verified merchant name, etc. I think Andreas plans to do the UI for that in the next update. On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach andr...@schildbach.dewrote: Just a small update. I merged the code to my bitcoinj-0.11 branch and put up binary .apk files for experimentation. Just make sure to tick BIP70 for tap-to-pay/scan-to-pay in the labs settings. Source: https://github.com/schildbach/bitcoin-wallet/commits/bitcoinj-0.11 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11 On 01/27/2014 12:59 PM, Andreas Schildbach wrote: As promised I'd like to present my work done on leveraging the payment protocol for face-to-face payments. The general assumption is that individuals don't own X.509 certificates. Their devices may be only badly connected to the internet or in some cases not at all. I've implemented a prototype on a branch of Bitcoin Wallet. It is using bitcoinj 0.11 (not released). https://github.com/schildbach/bitcoin-wallet/commits/payment-protocol -- 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 message delivery reliability
Hi Mike. Thanks for replying. On 1/30/2014 5:49 PM, Mike Hearn wrote: Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is, so any changes from this point on have to be backwards compatible. Then I think it's critically important to talk about failure situations now, rather than trying to patch on solutions later; it's going to be very hard to wedge/hack in fixes for potential problems when they could be addressed now with minor changes. Let's get some practical experience with what we've got so far. We can evolve PaymentRequest/Payment/PaymentACK in the right direction with backwards compatible upgrades, I am hoping. I think what I'm trying to discuss or find out here is whether the current PP description is defunct or incomplete in some manner, thus making any experience we gain from the current implementation moot. It seems the largest hole in the implementation is delivery of the Payment message, but I'm happy to accept that maybe I'm just missing something. A malicious merchant could claim he never received the Payment message, or a faulty network connection could cause the message to never be delivered. In arbitration the merchant could argue the transactions seen on the network were insufficient. To me, this could be a problem. 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 message delivery reliability
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.comwrote: In arbitration the merchant could argue the transactions seen on the network were insufficient. The arbitrator would presumably have some rules about what is or isn't an acceptable form of payment. HTTP has response codes for submission of the Payment message. We could add signing to PaymentACK and other things in future, if that turns out to be insufficient in practice. -- 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 message delivery reliability
On 1/30/2014 6:31 PM, Mike Hearn wrote: The arbitrator would presumably have some rules about what is or isn't an acceptable form of payment. Do you think this puts unnecessary trust into a third party? If the merchant instead signed and agreed to the unsigned transactions before they were broadcast (as in my OP), these arbitration concerns disappear. HTTP has response codes for submission of the Payment message. We could add signing to PaymentACK and other things in future, if that turns out to be insufficient in practice. HTTP isn't the only message delivery mechanism. Merchants can also lie: reply with 200 OK and an empty body. Or, reply with 404 not found and broadcast transactions anyway. 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 message delivery reliability
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com wrote: Hi Mike. Thanks for replying. On 1/30/2014 5:49 PM, Mike Hearn wrote: Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is, so any changes from this point on have to be backwards compatible. Then I think it's critically important to talk about failure situations now, rather than trying to patch on solutions later; it's going to be very hard to wedge/hack in fixes for potential problems when they could be addressed now with minor changes. Let's get some practical experience with what we've got so far. We can evolve PaymentRequest/Payment/PaymentACK in the right direction with backwards compatible upgrades, I am hoping. I think what I'm trying to discuss or find out here is whether the current PP description is defunct or incomplete in some manner, thus making any experience we gain from the current implementation moot. It seems the largest hole in the implementation is delivery of the Payment message, but I'm happy to accept that maybe I'm just missing something. A malicious merchant could claim he never received the Payment message, or a faulty network connection could cause the message to never be delivered. In arbitration the merchant could argue the transactions seen on the network were insufficient. You don't even have to assume malicious intent. A payment message could just fail to arrive because the server is unreachable. As the specification currently doesn't even suggest retrying, there is no way the merchant can rely at all on the memo and refund address being delivered, which makes them in my opinion useless. Your proposal makes the whole protocol more atomic, which may be a step too far at this point (though I like the idea very much), but I really think the specification should do everything possible to prevent transactions confirming without the payment message ever being delivered (i.e., store them in the sender's client, retry when necessary, exponential backoff, ...). -- 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 message delivery reliability
With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server error, and the UI would show that the payment failed. That seems straightforward and how I'd expect things to work as a user. On Thu, Jan 30, 2014 at 12:46 PM, Pieter Wuille pieter.wui...@gmail.comwrote: On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com wrote: Hi Mike. Thanks for replying. On 1/30/2014 5:49 PM, Mike Hearn wrote: Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is, so any changes from this point on have to be backwards compatible. Then I think it's critically important to talk about failure situations now, rather than trying to patch on solutions later; it's going to be very hard to wedge/hack in fixes for potential problems when they could be addressed now with minor changes. Let's get some practical experience with what we've got so far. We can evolve PaymentRequest/Payment/PaymentACK in the right direction with backwards compatible upgrades, I am hoping. I think what I'm trying to discuss or find out here is whether the current PP description is defunct or incomplete in some manner, thus making any experience we gain from the current implementation moot. It seems the largest hole in the implementation is delivery of the Payment message, but I'm happy to accept that maybe I'm just missing something. A malicious merchant could claim he never received the Payment message, or a faulty network connection could cause the message to never be delivered. In arbitration the merchant could argue the transactions seen on the network were insufficient. You don't even have to assume malicious intent. A payment message could just fail to arrive because the server is unreachable. As the specification currently doesn't even suggest retrying, there is no way the merchant can rely at all on the memo and refund address being delivered, which makes them in my opinion useless. Your proposal makes the whole protocol more atomic, which may be a step too far at this point (though I like the idea very much), but I really think the specification should do everything possible to prevent transactions confirming without the payment message ever being delivered (i.e., store them in the sender's client, retry when necessary, exponential backoff, ...). -- 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 message delivery reliability
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote: With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server error, and the UI would show that the payment failed. That seems straightforward and how I'd expect things to work as a user. That's one right way to do it imho, but not what is suggested or required by the specification, and not what bitcoin core master currently implements. -- 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 message delivery reliability
On 1/30/2014 7:02 PM, Pieter Wuille wrote: On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote: With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server error, and the UI would show that the payment failed. That seems straightforward and how I'd expect things to work as a user. That's one right way to do it imho, but not what is suggested or required by the specification, and not what bitcoin core master currently implements. If you sent the Payment message and the server goes silent after receiving it, you retry to delivery. However, the merchant can broadcast the transactions and force them into your wallet anyway. You could, quite likely, pay and never get an ACK. -- 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 message delivery reliability
On Thu, Jan 30, 2014 at 07:03:57PM +0700, Chuck wrote: On 1/30/2014 7:02 PM, Pieter Wuille wrote: On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote: With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server error, and the UI would show that the payment failed. That seems straightforward and how I'd expect things to work as a user. That's one right way to do it imho, but not what is suggested or required by the specification, and not what bitcoin core master currently implements. If you sent the Payment message and the server goes silent after receiving it, you retry to delivery. However, the merchant can broadcast the transactions and force them into your wallet anyway. You could, quite likely, pay and never get an ACK. I think in that case, you absolultely have to invalidate all the transactions in the Payment message by broadcasting a send-to-self transaction as soon as possible; until that point your wallet balance is indeterminate. Otherwise what will happen if the merchant did in fact receive the Payment message, and then processes it (and broadcasts the transaction) after some delay? Then what the user will see is: an apparently failed attempt to pay, leaving their wallet balance unchanged. Then, perhaps many hours later, their wallet balance will appear to spontaneously decrement. roy -- 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 message delivery reliability
If you sent the Payment message and the server goes silent after receiving it, you retry to delivery. However, the merchant can broadcast the transactions and force them into your wallet anyway. You could, quite likely, pay and never get an ACK. No retries. If there's a timeout the wallet will consider the payment not made, and if the merchant broadcasts anyway, the wallet will see the transactions and sync with them correctly. The ACK is not particularly important in the current design, so that's no big deal. If we see this situation crop up routinely we can take measures to improve things. I doubt we will. -- 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
