[Bitcoin-development] Payment Protocol for Face-to-face Payments
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 TAP TO PAY First I looked at the NFC tap-to-pay usecase. The way it works as currently rolled out: A BIP21 URL is published using an NDEF URI message. The URL is supplemented by a Bluetooth MAC address that can be connected in order to finish the payment. Once connected, a very simple custom protocol transmits the signed transaction(s) in bitcoin-serialized form to the payee, who replies with an ack or nack. The way I prototyped it to work in future: Instead of the BIP21 URL a BIP70 payment request is published using an NDEF MIME message (mime-type as per BIP71). The paymentUrl field can (and in the face-to-face case should) contain a Bluetooth URL which contains the MAC address of the payee. Because I could not find any standard for Bluetooth URLs, I made up my own: bt:112233445566 means MAC address 11:22:33:44:55:66. Once connected, Payment message and PaymentACK reply are used to finish the payment. Since Bluetooth sockets are streams, I had to use the delimited variant of the protobufs for Payment and PaymentACK messages. This prepends them with a VARINT containing the message length. All of the above should be easy to migrate. NFC implementations are rare, and the current Bluetooth protocol is implemented only by Bitcoin Wallet afaik. Fallbacks are provided where necessary. In future, I'd like to add encryption to the Bluetooth connection, maybe using SSL and some DH key exchange. SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: 1. The payment request is protobuf-serialized. For a simple payment request, this results in only ~50 bytes thanks to the efficiency of protobuf. 2. The bytes are encoded using Base43, which is the same as Base64/Base58, but its alphabet consists of the characters allowed in so-called alphanumeric QR-codes, minus the characters not allowed in URLs. 3. The resulting string is prefixed by BITCOIN: 4. All of that goes into a QR-code, and because it only contains alphanumeric characters, it will produce a very efficient code. For simple payment requests, I could not notice any difference in scanning difficulty. There are some limitations however: - Obviously such QR-encoded payment requests cannot grow in size as much as using other media. In particular, I expect PKI signed requests are out of question. However, in face to face payments the value of a sig based on PKI is highly questionable, and the fact the sig cannot be verified without TCP connectivity doesn't help. There should be some headroom for multiple-output requests and moderately more complex scripts though. - I chose to re-use the bitcoin: URL scheme, because it's already whitelisted in web browsers, QR-code scanners and so on. In order to differentiate payment requests URLs from BIP21 URLs, I test for uri.startsWith(BITCOIN:) because you'll get letters in all-caps from alphanumeric QR-codes. I will investigate into a better solution. - Due to wide deployment of BIP21 QR-codes, migration needs to happen in distinct phases. Ability to parse payment protocol URLs comes first, default to presenting them to users has to come (much) later. CLICK TO PAY Finally this is the usecase the payment protocol was invented for and it's not face-to-face. I don't have much to add, just one thing. As a byproduct of the above, payment protocol URLs can be used for links published on web pages as well. This might provide a nice replacement for the imho rather ugly BIP72 specification once the payment protocol is widely deployed. Open for discussion. -- 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] Payment Protocol for Face-to-face Payments
Thanks Andreas, that's really interesting work. Comments below. On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach andr...@schildbach.dewrote: Because I could not find any standard for Bluetooth URLs, I made up my own: bt:112233445566 means MAC address 11:22:33:44:55:66. I would like to see Bluetooth continue to work for scan-to-pay even in the signed case. So for this reason the current approach with a BTMAC parameter in the Bitcoin URI seems to work universally across NFC tags and QR codes, and would allow download of a signed PaymentRequest even in the case where a QR code is used. Because a Bitcoin URI already contains a public key (hash), re-using that to establish an encrypted/authd connection on top of an insecure RFCOMM socket would seem to be relatively straightforward. Obviously such QR-encoded payment requests cannot grow in size as much as using other media. In particular, I expect PKI signed requests are out of question. However, in face to face payments the value of a sig based on PKI is highly questionable, and the fact the sig cannot be verified without TCP connectivity doesn't help. Just a correction here - the reason signed payment requests are large (about 4000 bytes) is exactly because they *can* be verified offline, i.e. by a Trezor. The signed payment request contains all the data needed to establish its authenticity, including certificates and the signature itself. No TCP connection is needed. For face to face payments, I think signing is still useful. For one, we want to keep the distinction between merchant and user as blurry and indistinct as possible. A strong separation between merchants and consumers is one of the many bad things about the credit card system. Whilst initially we'd expect the payment protocol to be used by online webshops, in future it could be used by little corner shops, children's lemonade stands and so on. You don't want to exclude entire classes of transactions from being secure with Trezor type devices, and besides, even without a Trezor you probably still would like a receipt if you buy something from a local market trader. Another use case - we heard a story about a restaurant owner who accepted Bitcoin. He printed a static bitcoin URI onto a QR code on the menu. A month or two later he discovered one of his waiters had re-printed the menus with his own QR code! The people thought they had been paying for the meal, and in fact it went right into the pocket of the waiter. As to how it works, well, that's not hard. Comodo give away free email address certs with a few mouse clicks, it's no harder than signing up for a website. Then you can just open that cert file on your phone to install it and it should become usable automatically with a future version of bitcoinj. Email address doesn't prove a whole lot, of course, but it's better than nothing. If the restaurant owner had even just a hotmail address, he could have stuck it up behind the bar or painted it on the outside of his shop and some customer would have got suspicious when he didn't see the address (assuming we're successful at deploying it of course). - I chose to re-use the bitcoin: URL scheme Other wallets won't know what to do with it and would yield a strange error message. Finally this is the usecase the payment protocol was invented for and it's not face-to-face. I don't have much to add, just one thing. As a byproduct of the above, payment protocol URLs can be used for links published on web pages as well. This might provide a nice replacement for the imho rather ugly BIP72 specification once the payment protocol is widely deployed. URL length is limited on some versions of internet explorer (probably on all browsers). Rather than pack a file into a URL, if you don't want to use the current r= extension it's better for apps to just register to handle .bitcoinpaymentrequest files / the right MIME type. Downloading it and opening it would do the right thing automatically. Remember BIP 73 also! It says that with the apps built-in QR scanner, if you scan an HTTP[S] URI, you should try downloading it with a magic header. That way you can get a payment request file out of the server. Without the magic header (i.e. a normal generic barcode scanner app) it would open a web page containing a bitcoin URI clickable link. -- 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
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] Payment Protocol for Face-to-face Payments
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach andr...@schildbach.de wrote: On 01/27/2014 06:11 PM, Jeremy Spilman wrote: SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: Really interesting work. When using scan-to-pay, after the payer scans the QR code with the protobuf PaymentRequest (not a URL to download the PaymentRequest) are they using their own connectivity to submit the Payment response? How about putting a Bluetooth address in the payment_url inside the PaymentDetails message for the smartphone to send back the Payment response and get PaymentAck? That's exactly what I have prototyped. I am putting a Bluetooth MAC address into the payment_url. Have a look at the TAP TO PAY paragraph for details, its mostly the same mechanism. Same mechanism for both, of course. Sorry, that was obvious. :) -- 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] Payment Protocol for Face-to-face Payments
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach andr...@schildbach.dewrote: I'm not saying I'm against signed payment requests, but unfortunately they are just too big for QR-codes. Then again, QR-codes *can* take up to 2 KB. How big would a very basic trust chain plus signature be? As I said, the test requests generated by Gavin's generator end up being about 4kb. Unfortunately most certs are using RSA keys which aren't very compact. You can get ECC certs, but for whatever reason, the test requests aren't using one. I was under the impression that addresses will go away. Can you elaborate on the mechanism? There's still an address in the URI for backwards compatibility, right? In theory if everyone some day uses wallets that support BIP70 it'd be superfluous and could be removed, but whilst it's there, we could find alternative uses for it ... Ok, that's good news (to me). However, you are going to manage trust stores (adding and revoking) without TCP? Trust store is just a local database. Why would it involve TCP? Well I'm thinking the other way round. Use Bitcoin where its already used today -- face to face. Maybe in Berlin :-) Most of my transactions are sadly with online shops, still. you probably still would like a receipt if you buy something from a local market trader. Yes, but where is the problem? A receipt is a proof of purchase. If the payment request isn't signed then it proves nothing as you could have made it yourself. Of course paper receipts are forgeable too - we sort of pretend receipt fraudhttp://en.wikipedia.org/wiki/Return_frauddoes not exist, but it does. Nobody would ever be forced to sign to receive money, obviously, but it's better if people do as it leads to herd immunity. If people expect to see it then they will be suspicious if an attacker strips the signing data. If it's randomly hit/miss then the signing data can just be deleted by a MITM and you'd never think anything was amiss. And again, how is he going to provide the payment request to the payer without TCP? Over Bluetooth, perhaps. That's what we're talking about, right? Interesting, did not know about this BIP. However I don't understand the usecase. It was proposed by the BitPay guys. I think they feel that scanning a QR code should always make something intelligent happen, even if you don't (for instance) have a wallet app installed at all. Overloading the URL so it works for both web browsers and wallet apps is easy, so I can see why they suggested it. Doesn't seem like a big deal either way. -- 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] Payment Protocol for Face-to-face Payments
On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote: On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach andr...@schildbach.de wrote: SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: Really interesting work. When using scan-to-pay, after the payer scans the QR code with the protobuf PaymentRequest (not a URL to download the PaymentRequest) are they using their own connectivity to submit the Payment response? If we assume connectivity on the phone, might as well just get a URL from the QR code and re-use existing infrastructure for serving that? My first thought was likewise. In the case where the phone needs Internet connectivity anyway, why not include an HTTPS URL in a BIP 72 URL? I'm assuming that every client will have to support this is any case, since it's effectively mandated by the BIP, so why add another mode of operation? However, PaymentRequest-over-QR-code does seem to me to have one rather attractive advantage: the authentication model is orders of magnitude simpler and more intuitive for a face-to-face transaction than anything else. You're saying pay the coins to that thing over there displaying that QR code. Which, most of the time, is exactly what you want. In the web case, it's fine to ignore the case where the URL domain has been subverted (and an cert obtained by the attacker) because in that case you've lost before you even get to payments (MitM attacker shows you a modified web page with different payment details). But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... roy -- 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
[Bitcoin-development] Experiment with linking payment requests via href
On 01/27/2014 07:18 PM, Andreas Schildbach wrote: Rather than pack a file into a URL, if you don't want to use the current r= extension it's better for apps to just register to handle .bitcoinpaymentrequest files / the right MIME type. Downloading it and opening it would do the right thing automatically. That's a good point. I'll implement this asap. It doesn't look too good. I've tried Chrome, the AOSP browser and Firefox. All insist on handling the link with their download manager, which would involve an additional click. In the case of Chrome and AOSP, that download manager a separate component that is not updatable with the browser (rather its tied to the OS version afaik). If you click on the file in the download manager of Chrome and AOSP it opens as expected. On Firefox, it just ignores the click. I registered the correct mime type and also set the mime type of the href just in case. In case you want to have a look at the href, its on http://wallet.schildbach.de and links to Gavins generator. I didn't try suffixes, but I'd assume it behaves similar. Any ideas what else to try? -- 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] Experiment with linking payment requests via href
All insist on handling the link with their download manager, which would involve an additional click. That's the expected behaviour, right? That's why I said download and open. The Bitcoin URI with r= is better because it lets you remove that second click, but in some contexts the file approach is the right way to go - like for an email attachment or payment request sent via WhatsApp. -- 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
[Bitcoin-development] Extension for BIP-0070 to support recurring payments
Hi, [I sent this email 2 days ago prior my registration to the mailing list; please forgive me if this is a duplicate] I would like to propose an extension to the Payment Protocol (bip-0070) to address the case of recurring payments in Bitcoin -- new bip or modification of bip-0070. There has been a lot of growth in the last few years in the 'subscription economy' with many new companies embracing that model -- online video, gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a mainstream currency (hence bip-0070), and so the next logical step would be to define a protocol to address that need. We have been working in the past few years on an open-source billing platform (http://kill-bill.org/), and recently came with a prototype to do recurring billing in Bitcoin (see http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/). The work flow would look similar to the one from bip-0070. There would need to be some additions; the flow could be summarized as follow: 0. Click: 'Subscribe Now' 1. Wallet would get a RecurringPaymentRequestAuth which describes the nature of the future recurring payments 2. The Customer would get prompted from the wallet to authorize it. 3. The wallet would then poll the Merchant server (startup time, and/or well defined frequency) and potentially merchant would start issuing a PaymentRequest); the role of the wallet is to ensure that PaymentRequest is within the bounds of what was accepted by the customer-- amount, frequency,.. If it is, then it would make the Payment the same way it works for bip-0070 Is that something that the community would be interested in? We could provide more details about the protocol we have in mind (messages and flow), and also provide an implementation with bitcoinj as a wallet and Kill Bill as a merchant server. Le me know what you think. Stéphane-- 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] Extension for BIP-0070 to support recurring payments
+1 to the idea of recurring payment requests. Perhaps one way to realize this would be to add an optional URL to the PaymentRequest object where the next PaymentRequest can be fetched and the date at which the merchant expects the next payment. On Mon, Jan 27, 2014 at 6:36 PM, Stephane Brossier steph...@kill-bill.orgwrote: Hi, [I sent this email 2 days ago prior my registration to the mailing list; please forgive me if this is a duplicate] I would like to propose an extension to the Payment Protocol (bip-0070) to address the case of recurring payments in Bitcoin -- new bip or modification of bip-0070. There has been a lot of growth in the last few years in the 'subscription economy' with many new companies embracing that model -- online video, gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a mainstream currency (hence bip-0070), and so the next logical step would be to define a protocol to address that need. We have been working in the past few years on an open-source billing platform (http://kill-bill.org/), and recently came with a prototype to do recurring billing in Bitcoin (see http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/ ). The work flow would look similar to the one from bip-0070. There would need to be some additions; the flow could be summarized as follow: 0. Click: 'Subscribe Now' 1. Wallet would get a RecurringPaymentRequestAuth which describes the nature of the future recurring payments 2. The Customer would get prompted from the wallet to authorize it. 3. The wallet would then poll the Merchant server (startup time, and/or well defined frequency) and potentially merchant would start issuing a PaymentRequest); the role of the wallet is to ensure that PaymentRequest is within the bounds of what was accepted by the customer-- amount, frequency,.. If it is, then it would make the Payment the same way it works for bip-0070 Is that something that the community would be interested in? We could provide more details about the protocol we have in mind (messages and flow), and also provide an implementation with bitcoinj as a wallet and Kill Bill as a merchant server. Le me know what you think. Stéphane -- 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] Extension for BIP-0070 to support recurring payments
Yes, recurring payments and subscriptions is a frequently-requested feature. It needs a new BIP. Here is an outline: The situation is somewhat analogous to HTML5 local storage. The remote (merchant) wants to initiate a persistent behavior. This is bitcoin, so we have a push model for payment, and the user has complete control. The merchant can, at most, send a subscription request. The user is responsible for making on-time payments after that point. Centralized services like coinbase.com or blockchain.info will have an easy time of it. An automated program on their backend, sending payments as needed, is easy and direct. More inventive services might employ multisig transactions, generating and signing one signature of a TX, then sending that TX to the human for further signing and publishing. A few competing vendors could offer bots that provide this signing service. Decentralized, standalone wallet clients will be somewhat troublesome. We can store a local subscription request, and send recurring payments... if the wallet app is running. If not, the user will be missing payments, that perhaps they intended to make (rent!). Each of these solutions can be cancelled at any time by the user. As such, a courtesy subscription cancelled message sent to the merchant is recommended. User controls the usage of their money at all times, the way things should be. And finally, you do not want to make it /too easy/ to send money over and over again. From a human-interface perspective, a textual reminder to send money might be preferred over actual recurring payment automation: reminder email + manual spend inserts a bit of additional human thought and review into the process, with all that entails. -- 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] Extension for BIP-0070 to support recurring payments
It could be useful to schedule x payments for y amount every z time period, but you'd want to be able to pause or cancel at any time. If you want the merchant to be able to request a series of payments like a subscription, the merchant might also be able to request that the subscription be paused or cancelled as well. - - - - - - - - - - - - - - - - - - - Richard Kohl - rich...@pikapay.com Twitter: @generalseven Phone: +31 6 284 00112 PikaPay: Send Bitcoins with Twitter -- 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] Extension for BIP-0070 to support recurring payments
Greatly appreciate seeing this discussion occur. This is something that potentially could be supported through a bounty - possibly a process BIP? Possibly related: https://gist.github.com/ABISprotocol/8515891 Yes, recurring payments and subscriptions is a frequently-requested feature. It needs a new BIP. Here is an outline: The situation is somewhat analogous to HTML5 local storage. The remote (merchant) wants to initiate a persistent behavior. This is bitcoin, so we have a push model for payment, and the user has complete control. The merchant can, at most, send a subscription request. The user is responsible for making on-time payments after that point. Centralized services like coinbase.com or blockchain.info will have an easy time of it. An automated program on their backend, sending payments as needed, is easy and direct. More inventive services might employ multisig transactions, generating and signing one signature of a TX, then sending that TX to the human for further signing and publishing. A few competing vendors could offer bots that provide this signing service. Decentralized, standalone wallet clients will be somewhat troublesome. We can store a local subscription request, and send recurring payments... if the wallet app is running. If not, the user will be missing payments, that perhaps they intended to make (rent!). Each of these solutions can be cancelled at any time by the user. As such, a courtesy subscription cancelled message sent to the merchant is recommended. User controls the usage of their money at all times, the way things should be. And finally, you do not want to make it /too easy/ to send money over and over again. From a human-interface perspective, a textual reminder to send money might be preferred over actual recurring payment automation: reminder email + manual spend inserts a bit of additional human thought and review into the process, with all that entails. -- 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 -- 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] Extension for BIP-0070 to support recurring payments
I think the right approach for this is to actually implement it and *then* propose a BIP. There are so many possible features we could add to the payment protocol, any other approach would rapidly turn into lots of people deciding to do the fun bits and often leaving others doing the hard work with difficult or unworkable specs. For instance, if you try to implement this, you would rapidly discover that it probably makes more sense to do this as an additional set of fields in PaymentDetails rather than a new message type entirely. A new top level message type would in turn require new MIME types, URI extensions and so on. That doesn't make any sense. Once you decide to extend PaymentDetails, the next discovery would be that it probably makes sense to try and solve the problem of address re-use for recurring payments first, before speccing out time intervals and so on. That's a separate BIP. I'm all for adding recurring payments as a feature, that's what the protocol is there for. But I'd like to see future protocol extension requests come after at least one working implementation has been made . On Tue, Jan 28, 2014 at 3:36 AM, Stephane Brossier steph...@kill-bill.orgwrote: Hi, [I sent this email 2 days ago prior my registration to the mailing list; please forgive me if this is a duplicate] I would like to propose an extension to the Payment Protocol (bip-0070) to address the case of recurring payments in Bitcoin -- new bip or modification of bip-0070. There has been a lot of growth in the last few years in the 'subscription economy' with many new companies embracing that model -- online video, gaming, groceries, newspapers,... In parallel, Bitcoin is growing into a mainstream currency (hence bip-0070), and so the next logical step would be to define a protocol to address that need. We have been working in the past few years on an open-source billing platform (http://kill-bill.org/), and recently came with a prototype to do recurring billing in Bitcoin (see http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-experiment/ ). The work flow would look similar to the one from bip-0070. There would need to be some additions; the flow could be summarized as follow: 0. Click: 'Subscribe Now' 1. Wallet would get a RecurringPaymentRequestAuth which describes the nature of the future recurring payments 2. The Customer would get prompted from the wallet to authorize it. 3. The wallet would then poll the Merchant server (startup time, and/or well defined frequency) and potentially merchant would start issuing a PaymentRequest); the role of the wallet is to ensure that PaymentRequest is within the bounds of what was accepted by the customer-- amount, frequency,.. If it is, then it would make the Payment the same way it works for bip-0070 Is that something that the community would be interested in? We could provide more details about the protocol we have in mind (messages and flow), and also provide an implementation with bitcoinj as a wallet and Kill Bill as a merchant server. Le me know what you think. Stéphane -- 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
