[Bitcoin-development] Payment Protocol for Face-to-face Payments

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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Mike Hearn
At the moment there's no way to distinguish between a failed / rejected submission and a successful one beyond the freeform memo field, right? It'd be good if we had an error code field as well, perhaps for a future version.

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Andreas Schildbach
On 01/27/2014 03:54 PM, Gavin Andresen wrote: The purpose of PaymentACK is to give the customer reassurance that their payment request has been received and will be processed (or not). If it is syntactically incorrect or invalid in a way that the payment processor can detect right away then

Re: [Bitcoin-development] BIP70: PaymentACK semantics

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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-27 Thread Andreas Schildbach
On 01/27/2014 02:11 PM, Mike Hearn wrote: 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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-27 Thread Roy Badami
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

[Bitcoin-development] Experiment with linking payment requests via href

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

Re: [Bitcoin-development] Experiment with linking payment requests via href

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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Kevin Greene
+1 for an error field. Should the wallet broadcast the transaction to the bitcoin network when it receives an ACK, or always assume that the merchant server will do that? On Mon, Jan 27, 2014 at 7:52 AM, Mike Hearn m...@plan99.net wrote: At the moment there's no way to distinguish between a

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Pieter Wuille
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote: +1 for an error field. Agree, I think we need a way for client applications to interpret the response. Should the wallet broadcast the transaction to the bitcoin network when it receives an ACK, or always assume that the

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Kevin Greene
Should the wallet broadcast the transaction to the bitcoin network when it receives an ACK, or always assume that the merchant server will do that? In my opinion, that should be the primary meaning of receiving an ACK: acknowledgement that the receiver takes responsibility for getting the

[Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-01-27 Thread Stephane Brossier
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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-01-27 Thread Odinn Cyberguerrilla
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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

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

Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments

2014-01-27 Thread Jeff Garzik
Let's keep fund raising off this mailing list, please. PS bounties don't work. On Tue, Jan 28, 2014 at 1:08 AM, Odinn Cyberguerrilla odinn.cyberguerri...@riseup.net wrote: Greatly appreciate seeing this discussion occur. This is something that potentially could be supported through a