Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Ok, agreed. I will submit a pull request to BIP72 then. Not sure about escaping though. It is indeed not critical for bitcoin URIs, but still it is a part of RFC, don't think we should go against it. Andreas, we will implement this on our side, with bluetooth on r= and web address on r1=. 2014-07-01 18:59 GMT+01:00 Mike Hearn m...@plan99.net: Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect that escaping is largely unnecessary in many cases. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ 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
However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. So the idea here is that the recipient wallet both uploads to the internet and exposes the payment request over Bluetooth simultaneously, then let's the sending wallet pick whatever radio layer works best in its current conditions? I think having multiple r= params is reasonable, but the Bluetooth support is not specced in any BIP anyway. And if it were to be, people would point out the lack of link-layer encryption. So this is a bit tricky, overall. Right now I'd say things are kinda half baked: not only is bluetooth not standardised nor encrypted (my fault, I prototyped this code during a hackathon), but Bitcoin Wallet doesn't properly implement BIP 72 either. To push this work forward I think we need to sit down and do some more spec and implementation work :/ -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ 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 07/01/2014 10:18 AM, Mike Hearn wrote: However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. I think the way to go here is using multiple r= parameters. So the idea here is that the recipient wallet both uploads to the internet and exposes the payment request over Bluetooth simultaneously, then let's the sending wallet pick whatever radio layer works best in its current conditions? Either that, or just use the other ones as a fallback. Currently, Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r= URL fails. I think having multiple r= params is reasonable, but the Bluetooth support is not specced in any BIP anyway. And if it were to be, people would point out the lack of link-layer encryption. Its specced in code and implemented by several parties. I think its clear that link-layer encryption has to be an add-on to the current unencrypted connection, just like HTTPS is on top of HTTP. Anyway, that's unrelated to the question of how to provide fallback URLs. One more thought: We have a similar problem with the BIP70 payment URL. It doesn't allow for fallbacks either. I brought this issue up in the discussion phase of BIP70, but it was dismissed I think because of let's not get too complex for the first version. The fallback here is to send the transaction via the P2P network. (I think BIP70 via P2P radio will get used more often in future. I plan to look into Bluetooth 4 LE as soon as I have devices and wanted to try WIFI Direct again also. I hope we can skip BIP72 for both of those, but lets see.) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ 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
I think it makes more sense to not add a duplicate parameter. Current implementations will break if multiple r parameters are used (either reject the URI completely, or do something undefined). If a new parameter is used, then the current implementations will just ignore it if they don’t support it. - Michael Wozniak On Jul 1, 2014, at 5:48 AM, Andreas Schildbach andr...@schildbach.de wrote: On 07/01/2014 10:18 AM, Mike Hearn wrote: However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. I think the way to go here is using multiple r= parameters. So the idea here is that the recipient wallet both uploads to the internet and exposes the payment request over Bluetooth simultaneously, then let's the sending wallet pick whatever radio layer works best in its current conditions? Either that, or just use the other ones as a fallback. Currently, Bitcoin Wallet just falls back to BIP21 if fetching the PR via the r= URL fails. I think having multiple r= params is reasonable, but the Bluetooth support is not specced in any BIP anyway. And if it were to be, people would point out the lack of link-layer encryption. Its specced in code and implemented by several parties. I think its clear that link-layer encryption has to be an add-on to the current unencrypted connection, just like HTTPS is on top of HTTP. Anyway, that's unrelated to the question of how to provide fallback URLs. One more thought: We have a similar problem with the BIP70 payment URL. It doesn't allow for fallbacks either. I brought this issue up in the discussion phase of BIP70, but it was dismissed I think because of let's not get too complex for the first version. The fallback here is to send the transaction via the P2P network. (I think BIP70 via P2P radio will get used more often in future. I plan to look into Bluetooth 4 LE as soon as I have devices and wanted to try WIFI Direct again also. I hope we can skip BIP72 for both of those, but lets see.) -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ 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
In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ 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
Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ 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
Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other. I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ 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
Ok, one more idea: r= is used for the first URL, and we *think* of it as r0= additional URLs are appended as r1= r2= and so on. This would also define an ordering in case we need it. On 07/01/2014 05:07 PM, Michael Wozniak wrote: Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other. I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Hmm, r1, r2 etc is actually interesting. It takes less chars then array (yes, array brackets have to be escaped) and provides unlimited number of options, uniformed approach and priority definition. I'd say that is the way to go. Any objections? On 1 Jul 2014 16:39, Andreas Schildbach andr...@schildbach.de wrote: Ok, one more idea: r= is used for the first URL, and we *think* of it as r0= additional URLs are appended as r1= r2= and so on. This would also define an ordering in case we need it. On 07/01/2014 05:07 PM, Michael Wozniak wrote: Multiple parameters is currently undefined as far as I can tell. Should the client take the first, last, or ignore it completely if there are multiple of any parameter? I think that’s the point of the parameter pollution discussion, which will define it one way or the other. I’m only familiar with the Electrum implementation, which is currently checking for any duplicate parameters and treating the entire URI as invalid if duplicate parameters exist (following the parameter pollution suggestions). - Michael Wozniak On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote: Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd advocate for a simple array parameter name, like rs= (plural of r). Length really does matter for QR codes. I'm fine with either multiple r= params or exactly one r= plus zero to many r[]= params. Although I think it is a violation of the (current) spec to choke on more than one r= parameters, I admit that bitcoinj is currently implemented that way. (We could however fix this in a maintenance release.) However, r= should also allow all other protocols, exactly like any of the r[]= params. I don't think we should do a distinction here. Also because of backwards compatibility to the status quo. On 07/01/2014 03:03 PM, Alex Kotenko wrote: In my mind it's not like the client's phone is going all directions at the same time. There should be a priority method and fallback method(s). And I see p2p radio as priority, and web as fallback, and BIP21 in the end as always-working-default. So I'm keeping support for it all while want to be able to provide best user experience. Mike, a while ago in this thread you've described contactless cards user experience. I'm also using contactless cards often, and what I'm aiming at is creating same level of user experience for Bitcoin users. Encryption over bluetooth is a matter to worry about, and we will introduce that, but we need to sort out more low level problems first before coming into that stage. So, the backwards compatibility is a good issue Michael pointed out. While processing of multiple r parameters is indeed uncertain (since there is no RFC for that various implementations may behave differently), the array solution is somewhat better. The array parameter name is r%5B1%5D=, i.e. it's not r=, and we can add plain r= alongside. And if particular implementation understands the array construct - it will use it, otherwise it will ignore the r%5B1%5D= and use only usual r=. This doens't work though for cases where particular implementation understands array construct but doesn't work well with repeating parameters, since it will see two repeating r - an array and a string. I don't have a solution for that atm. If add completely new parameter to solve this we will need to make it an array straight away to address upcoming issues with accommodating other protocols. And then I would also modify existing BIP72 to strictly define r= as http(s) only parameter, while all other protocols (bluetooth, WiFi Direct, ultrasound, chirp etc) should go to the new array parameter. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect that escaping is largely unnecessary in many cases. -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ 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
It took some time but we have finally implemented bluetooth integration offered by Andreas in our bitcoin payment terminals. However it's not ideal at the moment. Basically the main problem is that in the BIP72 there is no way to provide a fallback alternative URI for payment request fetch if client wallet supports BIP70 but doesn't not support fetching over bluetooth or bluetooth connection fails for any reason. There is a way to define alternative URIs inside payment request itself, but that doesn't really work as client first needs to get payment request message itself somehow and this is exactly the problem. As far as I see there is three ways to solve that: 1. add new URI parameter for bluetooth address (e.g. r=http://web_addressrbt=bt:BT_MAC_addres). 2. allow multiple r parameters (e.g. r=http://web_addressr=bt:BT_MAC_addres). 3. allow r to be an array (e.g. r%5B0%5D=http://web_addressr%5B1%5D=bt:BT_MAC_addres). Option #1 isn't great at all, as it solves existing problem, but not provides any way to solve same problem appearing again for another possible protocol. Options #2 #3 may be working and seem to be nearly equal, and both are not great in the way that URI parser behavior in these cases is not clearly defined. I've checked through relevant RFCs and found nothing specific about this. According to my limited web experience the array scheme is working better than multiple repeating parameters. So I'm looking for some advice on which route of three proposed may be better here, or if there are any other ways I'm missing. 2014-03-27 13:31 GMT+00:00 vv01f vv...@riseup.net: Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation. Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only. Am 27.03.2014 um 11:08 schrieb Mike Hearn m...@plan99.net: But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ Bitcoin-development mailing list
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ 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
Companies can have a Cert with their name via CAcert. It requires some work though to get assured as an organisation. Did you already think about what CA is to be trusted or do users need to do that. The least good decision in my POV would be to accept OS/browser built in CAs only. Am 27.03.2014 um 11:08 schrieb Mike Hearn m...@plan99.net: But these cases are the norm, rather than the exception. Well, you're lucky, you live in Berlin. Most of the payments I make with Bitcoin are online, to websites. So this will differ between people. I wonder how critical it is. Let's say you are paying for a meal. In your head the place you're at is just the little Indian restaurant on the corner. In the companies register and therefore certificate it's something like Singh Food GmbH. That's probably good enough to prevent shenanigans. Even if there's a virus on your phone, it can't really replace the cert with a random stolen one, otherwise your meal could show up like IronCore Steel Inc or something that's obviously bogus. It'd have to be an incredibly smart virus that knew how to substitute one name for a different one, from a large library of stolen identities, such that the swap seemed plausible. That sounds very hard, certainly too hard to bother with for stealing restaurant fees. And if a waiter at the restaurant is corrupt and they replace the cert with one that's for their own 1-man business BP-Gupta or something, OK, you might pay the wrong person by mistake. But eventually the corrupt waiter will be discovered and then someone will have proof of what they did. It's FAR more likely they'd just strip the signature entirely and try to convince you the restaurant doesn't use BIP70 at all. Still, if we want to fix this, one approach I was thinking about is to have a super-cheesy CA just for us that issues certs with addresses in them, for any name you ask for. That is, if you say you want a cert for Shamrock Irish Pub, Wollishofen, Zurich, CH then it either sends a postcard to that address with a code to check ownership of the address, or it checks ownership of the place on Google Maps (which does the same postcard trick but for free!). That doesn't work for vending machines, but perhaps we just don't care about those. If a MITM steals your lunch money, boo hoo. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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 Fri, Mar 21, 2014 at 12:02:44AM +0100, Mike Hearn wrote: It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment I'd hope that people can get certs for their actual business name, but sometimes it does differ yes. The actual example I was thinking of is that of traditional British pubs. Often a company will own several pubs - however the pubs themselves will typically have individual traditional pub names. The name of the company might not be at all prominently advertised in the pubs. Traders at music festivals are another example that comes to mind (they often accept credit cards if they sell higher value items so why not Bitcoin?) In this example there often are no clearly advertised business names - at least, that the customer will be aware of. roy -- ___ 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
Yeah, for those cases we'd need to think of something else. That gets into the realm of creating our own infrastructure though ... -- ___ 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
But these cases are the norm, rather than the exception. Of all these places I spend my money at during the day I hardly ever know their official name. I'm thinking in terms of bakery, indian restaurant or snack vending machine. In Germany usually businesses are named like the people that run it. That usually just one or two random family names plus the legal form of the company. On 03/26/2014 11:56 PM, Mike Hearn wrote: Yeah, for those cases we'd need to think of something else. That gets into the realm of creating our own infrastructure though ... -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ 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
Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. On Fri, Mar 21, 2014 at 9:59 AM, Alex Kotenko alexy...@gmail.com wrote: 2014-03-21 10:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 06:31 PM, Jeff Garzik wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. Unfortunately it still is. At least here in Germany. Yes, it is a problem. Even in the middle of London you often can get into situation when cellphone network connectivity is not good enough for quick and reliable payment. Basement pubs, old buildings with thick walls, overcrowded places with overloaded radio environment. We should not rely on mobile connectivity in things like making payments. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. The usual issue is that they lack internet *for some customers*. The place may well have private wifi or hardwired connections that work. Even mobile networks may vary so some customers will have mobile connectivity and others won't. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
One participant, yes. Two participants lacking net would require a serious revisit of BIP 70's security assumptions and some design, at a minimum. On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach m...@monetize.io wrote: Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
I think it's mostly a UI issue. The recipient needs to understand that what he received is nothing more than an IOU that can be revoked at any time. If the UI makes it clear and the user trusts the sender, no problem. BIP70 would work as before. On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik jgar...@bitpay.com wrote: One participant, yes. Two participants lacking net would require a serious revisit of BIP 70's security assumptions and some design, at a minimum. On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach m...@monetize.io wrote: Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
I know that general approach to interaction design in Bitcoin assumes minimal to no difference between payer and payee, and generally I agree with this approach. However, for the sake of my PoS development this assumption is wrong by default, as PoS is a specialized hardware, and one who cared to buy and install it is probably not in the same situation as the other party that didn't care to by anything dedicated. In short - from PoS point of view there is a customer and a merchant. And my goal is to make thing work in assumption of fast and reliable connection on merchant side and no connection requirement at all from customer side. I didn't put a silly example, as of my experience there are really a lot of places where cellphone connection isn't good enough for reliable Bitcoin operation. However, if we're talking about merchant establishments - we can hope for private local WiFi or wired connection on PoS side, so PoS internet connection shouldn't be an issue. So this is the use case I'm designing around and this is why bluetooth based BIP70 implementation is important for me. I partly agree with Mike on user interface and IOU idea, but I have no intention to implement anything like that right now. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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 03/20/2014 05:14 PM, Alex Kotenko wrote: Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/ random_id_of_payment_request would be more usual and easily understandable. Agreed. I used the dash because I feared a slash would need to be escaped if used in an URL parameter. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. Thought of that as well. On the other hand, HTTP might be overkill and we inherit its potential downsides as well. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. Agreed. All I wanted to say support for QR is still small enough that we might be able to switch to an incompatible standard. If we're determined that is. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. Base 64 via binary QR: 64 chars / 256 chars == 6 bit / 8 bit = 0.75 Base 43 via alphanum QR: 43 chars / 45 chars == 5.43 bit / 5.49 bit = 0.99 That would be efficiency in terms of PR data size vs. amount space used in a QR code. Of course, the visual QR encoding also plays a role, for example its size is increased in discrete steps. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm convinced there is a lot of room for scanning improvements. How much of the payment protocol message size comes from use of x509? As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about 4000 bytes on top of that. As you can see, we have quite some room for improvements to PR payload (PaymentDetails). X.509 certification will probably not be possible via QR, at least not until specialized CA's will issue space-efficient certs (using ECDSA?). -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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 03/20/2014 06:31 PM, Jeff Garzik wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. Unfortunately it still is. At least here in Germany. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
+1 I couldn't do a better job at describing my motivation behind trying to stuff payment requests into QR codes. On 03/20/2014 10:52 PM, Roy Badami wrote: On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things I'm not sure if this what you're getting at, but in a common face-to-face scenario, it really doesn't overlap so much (in that the PKI in BIP70 isn't really helpful). It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment, nor any electronic identifier (domain name, email address) that might be presented to you in an X.509 certificate, even if such a certificate is presented in the PaymentRequest. In many cases I want/need to simply be assured that I am paying the person/organisation which operates that machine behind the counter, right there. In many ways I'll miss the simplicity of BIP21 QR codes for face-to-face transactions - because in this use case the payment protocol complicates (and in many cases weakens) the assurance that you really are paying the entity that prepared the QR code. roy -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Maybe its time to explore raw ECDSA signed message based certs. btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der format. And they contain a 2048-bit RSA server key, and 2048-bit RSA signatures (256byte each right there = 512bytes). And even 2048 is weaker than 256-bit ECDSA. Adam On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote: On 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago). You will want to stay below 500 bytes for convenient scanning. That said, I'm convinced there is a lot of room for scanning improvements. How much of the payment protocol message size comes from use of x509? As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about 4000 bytes on top of that. As you can see, we have quite some room for improvements to PR payload (PaymentDetails). X.509 certification will probably not be possible via QR, at least not until specialized CA's will issue space-efficient certs (using ECDSA?). -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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 Fri, Mar 21, 2014 at 11:59 AM, Adam Back a...@cypherspace.org wrote: Maybe its time to explore raw ECDSA signed message based certs. If you want to create and run a new CA, by all means. But I bet you don't. So we're stuck with the current system for now. btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der format. And they contain a 2048-bit RSA server key, and 2048-bit RSA signatures (256byte each right there = 512bytes). And even 2048 is weaker than 256-bit ECDSA. But you have to chain up to the root. The only reason more certs aren't ECC is backwards compatibility. Some old browsers don't know how to handle them. It wasn't so long ago that Fedora and Android were deleting ECC code from upstream libraries before shipping them, either for patent reasons for disk space saving measures. But it's possible to get ECC certs if you want. For example, Entrust is starting to sell them: http://www.entrust.net/ecc-certs/index.htm But their intermediate cert is still RSA. My understanding is that ECC roots for many CA's have been submitted and are now included, but of course give up compatibility with lots of users vs save a bit of cpu time and a handful of bytes is no real competition so it will be a long time until most websites are using ECC certs. Regardless, it's all irrelevant. Who knows when we might want to add another feature that uses some bytes into PaymentRequests. Stuffing them into a QR code will never make much sense IMO - it's far more sensible to just use Bluetooth where the data size constraints are so much easier. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
Oh, one other reason I found - apparently RIM, at least in the past, has been telling CA's that they need to pay mad bux for the Certicom ECC patents. So that's another reason why most certs are still using RSA. On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn m...@plan99.net wrote: On Fri, Mar 21, 2014 at 11:59 AM, Adam Back a...@cypherspace.org wrote: Maybe its time to explore raw ECDSA signed message based certs. If you want to create and run a new CA, by all means. But I bet you don't. So we're stuck with the current system for now. btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der format. And they contain a 2048-bit RSA server key, and 2048-bit RSA signatures (256byte each right there = 512bytes). And even 2048 is weaker than 256-bit ECDSA. But you have to chain up to the root. The only reason more certs aren't ECC is backwards compatibility. Some old browsers don't know how to handle them. It wasn't so long ago that Fedora and Android were deleting ECC code from upstream libraries before shipping them, either for patent reasons for disk space saving measures. But it's possible to get ECC certs if you want. For example, Entrust is starting to sell them: http://www.entrust.net/ecc-certs/index.htm But their intermediate cert is still RSA. My understanding is that ECC roots for many CA's have been submitted and are now included, but of course give up compatibility with lots of users vs save a bit of cpu time and a handful of bytes is no real competition so it will be a long time until most websites are using ECC certs. Regardless, it's all irrelevant. Who knows when we might want to add another feature that uses some bytes into PaymentRequests. Stuffing them into a QR code will never make much sense IMO - it's far more sensible to just use Bluetooth where the data size constraints are so much easier. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
According to Bernstein it's patent FUD (expired, ancient and solid prior art). http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html Adam On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: Oh, one other reason I found - apparently RIM, at least in the past, has been telling CA's that they need to pay mad bux for the Certicom ECC patents. So that's another reason why most certs are still using RSA. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Maybe so, but given the relatively minor advantages of ECC certs I can see why a CA might not want to take any risks. They are sitting ducks for patent trolls. I think ECC will still happen, though we end up back into NSA fear territory thanks to the stupid way secp256r1 was defined. *Hopefully* there's no back door. On Fri, Mar 21, 2014 at 1:25 PM, Adam Back a...@cypherspace.org wrote: According to Bernstein it's patent FUD (expired, ancient and solid prior art). http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html Adam On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: Oh, one other reason I found - apparently RIM, at least in the past, has been telling CA's that they need to pay mad bux for the Certicom ECC patents. So that's another reason why most certs are still using RSA. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
2014-03-21 9:47 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 05:14 PM, Alex Kotenko wrote: Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/ random_id_of_payment_request would be more usual and easily understandable. Agreed. I used the dash because I feared a slash would need to be escaped if used in an URL parameter. It will need to be escaped, but HTTP URLs used in BIP72 have it already, so don't see why we should bother. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. Thought of that as well. On the other hand, HTTP might be overkill and we inherit its potential downsides as well. It definitely is an overkill. Don't think we should do it now unless we will see later during implementation that we really have to. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. Agreed. All I wanted to say support for QR is still small enough that we might be able to switch to an incompatible standard. If we're determined that is. Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode it's limited to about 600 chars, so really I can include only unsigned and rather short payment request. Signed requests longer than few hundred bytes will not work. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. Base 64 via binary QR: 64 chars / 256 chars == 6 bit / 8 bit = 0.75 Base 43 via alphanum QR: 43 chars / 45 chars == 5.43 bit / 5.49 bit = 0.99 That would be efficiency in terms of PR data size vs. amount space used in a QR code. Of course, the visual QR encoding also plays a role, for example its size is increased in discrete steps. Ok, so base43-aphanum is winning about a quarter of capacity against base64-binary. I probably will skip this anyway and go with bluetooth URI scheme we've just agreed + old style payments over p2p network as fallback. So no payment requests in QR codes at all from my side. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
SPDY requires SSL and is even more complex than HTTP. Really, the current protocol we've got (length prefixed protobufs) is just fine except for the lack of encryption/authentication. For that you need to do ECDH to establish a shared AES session key, and MAC each packet. Like I said, it's not entirely trivial which is why it's worth trying SSL too, but it's also not a massive effort. On Fri, Mar 21, 2014 at 4:20 PM, Andreas Schildbach andr...@schildbach.dewrote: On 03/21/2014 02:54 PM, Alex Kotenko wrote: I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. Thought of that as well. On the other hand, HTTP might be overkill and we inherit its potential downsides as well. It definitely is an overkill. Don't think we should do it now unless we will see later during implementation that we really have to. Btw. we could also consider SPDY. I'm not sure about the advantages, but its probably quicker and leaner. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
2014-03-21 14:51 GMT+00:00 Andreas Schildbach andr...@schildbach.de: Quoting from RFC 3986, Section 3.4. Query: The characters slash (/) and question mark (?) may represent data within the query component. Ok. So BIP72 with a BT URI in the 'r' parameter? Yes. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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 03/20/2014 03:22 AM, Alex Kotenko wrote: Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. We could use Bluetooth in the r parameter, not unlike we use Bluetooth in the payment_url. However, since multiple devices could access your machine at the same time, we need some for of adressibility of different payment requests. Something like bt:btmac-random_id_of_payment_request. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? Alphanumeric QR codes have an alphabet of 45 chars, of which I am using 43. I skipped Space and '%' because they're not allowed in URIs. When I invented the Base43 format back in 2011, wanted it to be URI compatible so we can use the Android intent dispatcher. If we let go of the URI requirement, we can use binary QR codes as well. This means users will always have to manually start their Bitcoin app first. (Also, there is an implementation issue with the ZXing scanner I'm using, it returns Strings rather than a byte array so it will choke on \0 characters.) And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? I took this into consideration. It would be space inefficient. The Base58-encoded address from BIP21 forces the QR code into binary mode. Still you can't encode the payment request extension (probably an URL parameter) as binary because it needs to stay compatible to the URI standard (RFC 3986). You could use one of the Base64 variants for the PR in this case, but still it would be inefficient. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Very, very limited. The more data you stuff in them, the less reliable and slower scanning becomes. A URL is about the limit of what's practically achievable. Even with that, BitPay have been complaining about the increased character length from adding the https url to download the payment request (though not escaping reduces character count by a lot and is valid). X.509 is extremely bloated, partly due to the number of features it supports, partly due to its history but mostly due to the widespread use of RSA which generates giant keys and signatures. Of course you can get ECC certs as well, but in practice most merchants don't seem to use them yet. There's no way you can fit a cert chain into a QR code. However, this is no big deal, because for the serverless PoS device case Alex cares about you need a backchannel to submit the transaction and refund address anyway, so Bluetooth is already useful/required. Downloading the payment request via it as well as uploading the response is not a big change and - as mentioned - already implemented by Andreas and myself some time ago. On Thu, Mar 20, 2014 at 1:12 PM, Adam Back a...@cypherspace.org wrote: Whats a sensible limit on practical/convenient QR code size? How much of the payment protocol message size comes from use of x509? (Just exploring what the options are). Adam On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
2014-03-20 8:08 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 03:22 AM, Alex Kotenko wrote: Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. We could use Bluetooth in the r parameter, not unlike we use Bluetooth in the payment_url. However, since multiple devices could access your machine at the same time, we need some for of adressibility of different payment requests. Something like bt:btmac- random_id_of_payment_request. I guess this would be best option. I'm also worried about potential QR code capacity, since as I imagine we can encounter device that has your Wallet installed and bluetooth enabled, but no NFC available, so we will have to operate via onscreen QR codes + bluetooth. Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing URI's patterns. BT is strictly point-to-point connection, so BT MAC should be considered as server address, and payment request ID can be considered as request path. Probably bt:bt-mac/random_id_of_payment_request would be more usual and easily understandable. Really I don't think my PoS will now support multiple simultaneous payments, but it's good to have this thing in place for the time I will need it. I wonder how complex it would be to implement HTTP-over-Bluetooth. Not like I'm willing to do that now, but HTTP is well known and proven to be quite good for tasks like this, so in theory it would be handy to have such capacities in here. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. Well, do we need to be compatible? If the dev community decides Base43 PR QR's (or whatever other self-contained format) is the way to go, we just implement, roll it out and use it. My PoS needs to be compatible with BIP21, as when I'm presenting QR code or sending NFC message - I have no way to tell what wallet/phone is on the accepting side, so I have to be compatible to existing widely supported technologies. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? Alphanumeric QR codes have an alphabet of 45 chars, of which I am using 43. I skipped Space and '%' because they're not allowed in URIs. When I invented the Base43 format back in 2011, wanted it to be URI compatible so we can use the Android intent dispatcher. If we let go of the URI requirement, we can use binary QR codes as well. This means users will always have to manually start their Bitcoin app first. (Also, there is an implementation issue with the ZXing scanner I'm using, it returns Strings rather than a byte array so it will choke on \0 characters.) And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? I took this into consideration. It would be space inefficient. The Base58-encoded address from BIP21 forces the QR code into binary mode. Still you can't encode the payment request extension (probably an URL parameter) as binary because it needs to stay compatible to the URI standard (RFC 3986). You could use one of the Base64 variants for the PR in this case, but still it would be inefficient. Well, yes, it would be less efficient than base43. But did you calculate how much less? It's a compatible and already widely used way and loosing compatibility needs to have serious reasons, so would be great to know exact figures here. I can find out base64 size, but I don't have a working base43 implementation (since the only existing is in Java, and I don't speak it). Can you give me a sample uncompressed PR file of moderate size and a base43 encoded version of it? And I'll convert it into base64 and compare. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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 Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote: Whats a sensible limit on practical/convenient QR code size? Extremely limited. Preferably under 100 bytes. You will see increasingly poor operating in varying light conditions, such as paying via QR code on a printed receipt in a pub at night. That was one of the motivations for BIP 73. On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach andr...@schildbach.de wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com: On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote: Whats a sensible limit on practical/convenient QR code size? Extremely limited. Preferably under 100 bytes. You will see increasingly poor operating in varying light conditions, such as paying via QR code on a printed receipt in a pub at night. That was one of the motivations for BIP 73. Hmm, in this case I think base43 discussion is irrelevant. Even with best space utilization we can get we will not be able to fit in anything bigger than a smallest unsigned payment certificate. And that is not so useful. So probably we should stick with BIP73 approach and bluetooth URI scheme we're inventing. On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach andr...@schildbach.de wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
It really depends on the physical, real world size of the QR code. If you have a big screen, and security permits displaying a larger QR code, you can afford more bytes. If you are displaying a tiny postage stamp 1-2cm in size, the practical byte limit is very low. Ideally, you test your QR codes in real world conditions, before picking the best path. On Thu, Mar 20, 2014 at 1:42 PM, Alex Kotenko alexy...@gmail.com wrote: 2014-03-20 17:31 GMT+00:00 Jeff Garzik jgar...@bitpay.com: On Thu, Mar 20, 2014 at 8:12 AM, Adam Back a...@cypherspace.org wrote: Whats a sensible limit on practical/convenient QR code size? Extremely limited. Preferably under 100 bytes. You will see increasingly poor operating in varying light conditions, such as paying via QR code on a printed receipt in a pub at night. That was one of the motivations for BIP 73. Hmm, in this case I think base43 discussion is irrelevant. Even with best space utilization we can get we will not be able to fit in anything bigger than a smallest unsigned payment certificate. And that is not so useful. So probably we should stick with BIP73 approach and bluetooth URI scheme we're inventing. On Thu, Mar 20, 2014 at 4:09 AM, Andreas Schildbach andr...@schildbach.de wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket, address, 1234, true) to wrap a bluetooth socket in SSL. However I have not tried it. For now, just prototype and build your product without the security. We can find someone to experiment with this, if you don't want to . Bluetooth needs encryption and MACs as well as signing to be secure, because there could be radio MITM. Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things. On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko alexy...@gmail.com wrote: Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
We'll see how it will go, maybe I will get to implement this somewhere soon. Yes, I'm thinking exactly about radio MitM attacks possible with bluetooth. I'll also look into using PKI inside the PoS for the merchant. It would be great user experience if we would be able to provide a signed payment request with human recognizable merchant identity name in the way you described much earlier in Bitcoin 0.9 FAQ. 2014-03-20 18:31 GMT+00:00 Mike Hearn m...@plan99.net: With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket, address, 1234, true) to wrap a bluetooth socket in SSL. However I have not tried it. For now, just prototype and build your product without the security. We can find someone to experiment with this, if you don't want to . Bluetooth needs encryption and MACs as well as signing to be secure, because there could be radio MITM. Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things. On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko alexy...@gmail.com wrote: Hmm, is there any other way to do it? Can we provide a signed payment request and verify the sign on receiving side and this way protect from bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't a very well developed area, and my own skills are not enough to quickly implement a reliable secure solution here. 2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net: Encoding entire payment requests into qrcodes is definitely not the way to go. They can already be large when signed and we're just at the start of adding features. Finishing off and standardising the bluetooth support is the way to go (r=bt:mac). Andreas' app already has some support for this I believe, so Alex you could prototype with that, but we need to: 1) Add an encryption/auth layer on top, because it runs over RFCOMM sockets. The authentication would require proof of owning the Bitcoin key that's in the address part of the URI (which is needed for backwards compat anyway). 2) Write a BIP for it and make sure it's interoperable For the auth layer we could either use SSL and then just ignore the server certificate and require signing of the session public key with the Bitcoin key, which should be easy to code up but is rather heavy on the air, or roll a custom lightweight thing where we just do a basic ECDH, with the servers key being the same as the address key. But rolling such protocols is subtle and I guess it'd need to be reviewed by people familiar with such things. This feels like a good opportunity to grow the community - perhaps we can find a volunteer in the forums who enjoys crypto. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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 Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote: Yes, this overlaps somewhat with the PKI signing in BIP70, but not entirely - you might want to serve unsigned payment requests, but still have confidentiality and authenticity for a local face to face transaction. The signing and encryption does different things I'm not sure if this what you're getting at, but in a common face-to-face scenario, it really doesn't overlap so much (in that the PKI in BIP70 isn't really helpful). It's not unusual, in a face-to-face transaction at a bricks-and-mortar establishment, that you know neither the legal name of the entity running the establishment, nor any electronic identifier (domain name, email address) that might be presented to you in an X.509 certificate, even if such a certificate is presented in the PaymentRequest. In many cases I want/need to simply be assured that I am paying the person/organisation which operates that machine behind the counter, right there. In many ways I'll miss the simplicity of BIP21 QR codes for face-to-face transactions - because in this use case the payment protocol complicates (and in many cases weakens) the assurance that you really are paying the entity that prepared the QR code. roy -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ 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
Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn m...@plan99.net: Thanks Andreas. For BIP standardisation, I think the VIEW intent seems like an obvious one. Bluetooth support probably should come later if/when we put encryption/auth on the RFCOMM link (probably SSL). -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
Take a look at BIP 73: https://github.com/bitcoin/bips/blob/master/bip-0073.mediawiki On Wed, Mar 19, 2014 at 10:22 PM, Alex Kotenko alexy...@gmail.com wrote: Hi Andreas I'm implementing support for BIP70 in my POS at the moment, and I've just realized that with options you're proposing usecase I'm looking for is not covered. Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I need to still be able to use it for backwards compatibility. But at the same time I want to be able to support BIP70. And also I want to avoid using external servers, the concept of my POS is that everything is happening between just payer's phone and payee's POS device. This means that BIP72 HTTP(S) link inside Bitcoin URI is not suitable for me. You're also offering an option to include Base43 encoded PR body right inside the Bitcoin URI, but in a way that is not backwards compatible with BIP21. In the end this all means that there is no way for me to at the same time keep backwards compatibility with all wallets not supporting NFC and BIP70 (all other wallets right now), and keep things inside POS without need for external servers. I understand your intention behind base43 encoding and noncompatible URI - you want to make most possible use of QR codes. But I wonder - did you compare this base43 to base64 encoded request in a binary QR code format? How much do we actually win in total bytes capacity at a price of noncompatibility and increased complexity? And also maybe we can extend BIP72 to include encoded payment request in the URL directly in a backwards compatible way? Best regards, Alex Kotenko 2014-03-02 11:50 GMT+00:00 Mike Hearn m...@plan99.net: Thanks Andreas. For BIP standardisation, I think the VIEW intent seems like an obvious one. Bluetooth support probably should come later if/when we put encryption/auth on the RFCOMM link (probably SSL). -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ 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
I've written up a document about all the different methods on how the payment protocol (both the old one and BIP70) is used in Bitcoin Wallet. It only provides an overview -- I plan to go into details with separate (BIP?) documents where needed. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests If you have any questions about compatibility, don't hesitate to contact me. 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. [...] -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/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
I have refreshed the Bitcoin Wallet preview version with beta version 3.32. It now implements BIP72 aka URI extension for payment protocol. There is one important deviation from the standard though: Bitcoin URI address and amount fields need to correspond to the data from the payment request. The makes sure the signature really signs the URI (which you've gotten directly from the payee) and not a malicious payment request introduced by a MITM. Note the memo isn't protected like that, so it can still be MITM'ed. I know this means that for the time being Bitcoin URIs must be backwards compatible. That should not be an issue since we will be in transition phase for many months anyway. Until then, I hope we will have agreed on a more sophisticated approach, e.g. a separate hash in the URI. Source: https://github.com/schildbach/bitcoin-wallet/commits/v3.32 Binaries: https://github.com/schildbach/bitcoin-wallet/releases/tag/v3.32 (also published to the corresponding channels on Google Play) On 01/30/2014 11:46 AM, Andreas Schildbach wrote: 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 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/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
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] 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] Payment Protocol for Face-to-face Payments
But the face-to-face case isn't intrinsically dependent on SSL security, and it's nice not to introduce that attack vector... If the only concern is to make scan-to-pay work without reliance on SSL's PKI, it might be better to specify the payment protocol url *and* the public key used for signing right in the qr code. The wallet connects to the url, fetches the payment request (maybe over a secure connection, maybe not, doesn't matter), and verifies the signature matches the public key from the qr code. Downsides compared to embedding the entire request: Payee needs to host/serve requests somewhere online. This introduces reliability and DoS concerns. Payer needs an internet connection to fetch the request. Advantages: Serve variable payment requests from the same qr code (improving recipient privacy). Still no hard dependency on CAs. Even if both CA and DNS are compromised by an attacker, the worst they can do is Denial of Service. Optionally use CAs so that the wallet can attach an identity to who you're paying by QR code. This partly addresses the problem of the waiter overwriting the QR code. A non-PKI transaction would simply show Unknown recipient. Much smaller QR code (only overhead is the key parameter, and you could use a boolean param + the address as public key hack Mike mentionned, for only 4 characters of overhead). No need for a backward-incompatible bitcoin: scheme On Mon, Jan 27, 2014 at 3:34 PM, Roy Badami r...@gnomon.org.uk wrote: 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 -- 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
[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] 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
