* [Bitcoin-development] Payment Protocol for Face-to-face Payments
@ 2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
` (3 more replies)
0 siblings, 4 replies; 69+ messages in thread
From: Andreas Schildbach @ 2014-01-27 11:59 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 69+ messages in thread* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach @ 2014-01-27 13:11 ` Mike Hearn 2014-01-27 18:18 ` Andreas Schildbach 2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-01-27 13:11 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4374 bytes --] Thanks Andreas, that's really interesting work. Comments below. On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach <andreas@schildbach•de>wrote: > 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. [-- Attachment #2: Type: text/html, Size: 5703 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 13:11 ` Mike Hearn @ 2014-01-27 18:18 ` Andreas Schildbach 2014-01-27 18:34 ` Mike Hearn 2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach 0 siblings, 2 replies; 69+ messages in thread From: Andreas Schildbach @ 2014-01-27 18:18 UTC (permalink / raw) To: bitcoin-development On 01/27/2014 02:11 PM, Mike Hearn wrote: > I would like to see Bluetooth continue to work for scan-to-pay even in > the signed case. So for this reason the current approach with a BTMAC > parameter in the Bitcoin URI seems to work universally across NFC tags > and QR codes, and would allow download of a signed PaymentRequest even > in the case where a QR code is used. 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? > 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. I was under the impression that addresses will go away. Can you elaborate on the mechanism? > 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. Ok, that's good news (to me). However, you are going to manage trust stores (adding and revoking) without TCP? > 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. Ack. > 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. Well I'm thinking the other way round. Use Bitcoin where its already used today -- face to face. > you probably still would like a receipt if you buy > something from a local market trader. Yes, but where is the problem? > 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. Sad story, but it's really a special case. Using a printed QR-code is clearly the wrong tool for his task, for several reasons. And again, how is he going to provide the payment request to the payer without TCP? > 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. We don't want to force people to sign up anywhere. Bitcoin is instant-on. > - 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. Which is why I said we need some transition time. > Rather than pack a file into a URL, if you don't want to > use the current r= extension it's better for apps to just register to > handle .bitcoinpaymentrequest files / the right MIME type. Downloading > it and opening it would do the right thing automatically. That's a good point. I'll implement this asap. > 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. Interesting, did not know about this BIP. However I don't understand the usecase. Its not like my browsers always display QR-codes with URL of the page being shown. And if the page in question bothers to show a QR code, it could just as well also link to a payment request resource (as suggested above). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 18:18 ` Andreas Schildbach @ 2014-01-27 18:34 ` Mike Hearn 2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach 1 sibling, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-01-27 18:34 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2606 bytes --] On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach <andreas@schildbach•de>wrote: > 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 fraud<http://en.wikipedia.org/wiki/Return_fraud>does 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. [-- Attachment #2: Type: text/html, Size: 4880 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* [Bitcoin-development] Experiment with linking payment requests via href 2014-01-27 18:18 ` Andreas Schildbach 2014-01-27 18:34 ` Mike Hearn @ 2014-01-27 20:53 ` Andreas Schildbach 2014-01-27 21:47 ` Mike Hearn 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-01-27 20:53 UTC (permalink / raw) To: bitcoin-development On 01/27/2014 07:18 PM, Andreas Schildbach wrote: >> Rather than pack a file into a URL, if you don't want to >> use the current r= extension it's better for apps to just register to >> handle .bitcoinpaymentrequest files / the right MIME type. Downloading >> it and opening it would do the right thing automatically. > > That's a good point. I'll implement this asap. It doesn't look too good. I've tried Chrome, the AOSP browser and Firefox. All insist on handling the link with their download manager, which would involve an additional click. In the case of Chrome and AOSP, that download manager a separate component that is not updatable with the browser (rather its tied to the OS version afaik). If you click on the file in the download manager of Chrome and AOSP it opens as expected. On Firefox, it just ignores the click. I registered the correct mime type and also set the mime type of the href just in case. In case you want to have a look at the href, its on http://wallet.schildbach.de and links to Gavins generator. I didn't try suffixes, but I'd assume it behaves similar. Any ideas what else to try? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Experiment with linking payment requests via href 2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach @ 2014-01-27 21:47 ` Mike Hearn 0 siblings, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-01-27 21:47 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 398 bytes --] > > All insist on handling the link with their download manager, which would > involve an additional click. That's the expected behaviour, right? That's why I said "download and open". The Bitcoin URI with r= is better because it lets you remove that second click, but in some contexts the file approach is the right way to go - like for an email attachment or payment request sent via WhatsApp. [-- Attachment #2: Type: text/html, Size: 637 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach 2014-01-27 13:11 ` Mike Hearn @ 2014-01-27 17:11 ` Jeremy Spilman 2014-01-27 17:39 ` Andreas Schildbach 2014-01-27 20:34 ` Roy Badami 2014-01-30 10:46 ` Andreas Schildbach 2014-03-02 9:47 ` Andreas Schildbach 3 siblings, 2 replies; 69+ messages in thread From: Jeremy Spilman @ 2014-01-27 17:11 UTC (permalink / raw) To: bitcoin-development, Andreas Schildbach On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach <andreas@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? 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? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman @ 2014-01-27 17:39 ` Andreas Schildbach 2014-01-27 18:18 ` Jeremy Spilman 2014-01-27 20:34 ` Roy Badami 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-01-27 17:39 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 17:39 ` Andreas Schildbach @ 2014-01-27 18:18 ` Jeremy Spilman 0 siblings, 0 replies; 69+ messages in thread From: Jeremy Spilman @ 2014-01-27 18:18 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development On Jan 27, 2014, at 9:39 AM, Andreas Schildbach <andreas@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. :) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman 2014-01-27 17:39 ` Andreas Schildbach @ 2014-01-27 20:34 ` Roy Badami 2014-01-29 14:57 ` Christophe Biocca 1 sibling, 1 reply; 69+ messages in thread From: Roy Badami @ 2014-01-27 20:34 UTC (permalink / raw) To: Jeremy Spilman; +Cc: bitcoin-development, Andreas Schildbach On Mon, Jan 27, 2014 at 09:11:08AM -0800, Jeremy Spilman wrote: > On Mon, 27 Jan 2014 03:59:25 -0800, Andreas Schildbach > <andreas@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 20:34 ` Roy Badami @ 2014-01-29 14:57 ` Christophe Biocca 0 siblings, 0 replies; 69+ messages in thread From: Christophe Biocca @ 2014-01-29 14:57 UTC (permalink / raw) To: Roy Badami; +Cc: bitcoin-development, Andreas Schildbach > 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 <roy@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 >> <andreas@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=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach 2014-01-27 13:11 ` Mike Hearn 2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman @ 2014-01-30 10:46 ` Andreas Schildbach 2014-01-30 10:50 ` Mike Hearn 2014-02-07 23:15 ` Andreas Schildbach 2014-03-02 9:47 ` Andreas Schildbach 3 siblings, 2 replies; 69+ messages in thread From: Andreas Schildbach @ 2014-01-30 10:46 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-30 10:46 ` Andreas Schildbach @ 2014-01-30 10:50 ` Mike Hearn 2014-02-07 23:15 ` Andreas Schildbach 1 sibling, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-01-30 10:50 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1863 bytes --] 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 <andreas@schildbach•de>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=123612991&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3003 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-30 10:46 ` Andreas Schildbach 2014-01-30 10:50 ` Mike Hearn @ 2014-02-07 23:15 ` Andreas Schildbach 1 sibling, 0 replies; 69+ messages in thread From: Andreas Schildbach @ 2014-02-07 23:15 UTC (permalink / raw) To: bitcoin-development 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=123612991&iu=/4140/ostg.clktrk > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach ` (2 preceding siblings ...) 2014-01-30 10:46 ` Andreas Schildbach @ 2014-03-02 9:47 ` Andreas Schildbach 2014-03-02 11:50 ` Mike Hearn 3 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-02 9:47 UTC (permalink / raw) To: bitcoin-development 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. > [...] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-02 9:47 ` Andreas Schildbach @ 2014-03-02 11:50 ` Mike Hearn 2014-03-20 2:22 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-02 11:50 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 204 bytes --] 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). [-- Attachment #2: Type: text/html, Size: 323 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-02 11:50 ` Mike Hearn @ 2014-03-20 2:22 ` Alex Kotenko 2014-03-20 3:31 ` Jeff Garzik 2014-03-20 8:08 ` Andreas Schildbach 0 siblings, 2 replies; 69+ messages in thread From: Alex Kotenko @ 2014-03-20 2:22 UTC (permalink / raw) To: Bitcoin Dev; +Cc: Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 2401 bytes --] 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 <mike@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=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 4888 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 2:22 ` Alex Kotenko @ 2014-03-20 3:31 ` Jeff Garzik 2014-03-20 8:09 ` Andreas Schildbach 2014-03-20 8:08 ` Andreas Schildbach 1 sibling, 1 reply; 69+ messages in thread From: Jeff Garzik @ 2014-03-20 3:31 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 3350 bytes --] 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 <alexykot@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 <mike@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=126839071&iu=/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/ [-- Attachment #2: Type: text/html, Size: 6556 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 3:31 ` Jeff Garzik @ 2014-03-20 8:09 ` Andreas Schildbach 2014-03-20 10:36 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-20 8:09 UTC (permalink / raw) To: bitcoin-development Afaik, BIP73 needs an external server (the web server). On 03/20/2014 04:31 AM, Jeff Garzik wrote: > 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 <alexykot@gmail•com > <mailto:alexykot@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 <mike@plan99•net > <mailto:mike@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=126839071&iu=/4140/ostg.clktrk > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > <mailto: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 > <mailto: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 > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 8:09 ` Andreas Schildbach @ 2014-03-20 10:36 ` Mike Hearn 2014-03-20 12:12 ` Adam Back 2014-03-20 18:20 ` Alex Kotenko 0 siblings, 2 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-20 10:36 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1224 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 1625 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 10:36 ` Mike Hearn @ 2014-03-20 12:12 ` Adam Back 2014-03-20 12:20 ` Mike Hearn ` (2 more replies) 2014-03-20 18:20 ` Alex Kotenko 1 sibling, 3 replies; 69+ messages in thread From: Adam Back @ 2014-03-20 12:12 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 12:12 ` Adam Back @ 2014-03-20 12:20 ` Mike Hearn 2014-03-20 17:31 ` Jeff Garzik 2014-03-21 10:25 ` Andreas Schildbach 2 siblings, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-20 12:20 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 2753 bytes --] 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 <adam@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. >> > [-- Attachment #2: Type: text/html, Size: 3459 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 12:12 ` Adam Back 2014-03-20 12:20 ` Mike Hearn @ 2014-03-20 17:31 ` Jeff Garzik 2014-03-20 17:42 ` Alex Kotenko 2014-03-21 10:28 ` Andreas Schildbach 2014-03-21 10:25 ` Andreas Schildbach 2 siblings, 2 replies; 69+ messages in thread From: Jeff Garzik @ 2014-03-20 17:31 UTC (permalink / raw) To: Adam Back, Andreas Schildbach; +Cc: Bitcoin Dev On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@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 <andreas@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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 17:31 ` Jeff Garzik @ 2014-03-20 17:42 ` Alex Kotenko 2014-03-20 18:01 ` Jeff Garzik 2014-03-21 10:28 ` Andreas Schildbach 1 sibling, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-03-20 17:42 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1761 bytes --] 2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik@bitpay•com>: > On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@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 > <andreas@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 > [-- Attachment #2: Type: text/html, Size: 3128 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 17:42 ` Alex Kotenko @ 2014-03-20 18:01 ` Jeff Garzik 0 siblings, 0 replies; 69+ messages in thread From: Jeff Garzik @ 2014-03-20 18:01 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Andreas Schildbach 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 <alexykot@gmail•com> wrote: > 2014-03-20 17:31 GMT+00:00 Jeff Garzik <jgarzik@bitpay•com>: >> >> On Thu, Mar 20, 2014 at 8:12 AM, Adam Back <adam@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 >> <andreas@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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 17:31 ` Jeff Garzik 2014-03-20 17:42 ` Alex Kotenko @ 2014-03-21 10:28 ` Andreas Schildbach 2014-03-21 13:59 ` Alex Kotenko 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 10:28 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 10:28 ` Andreas Schildbach @ 2014-03-21 13:59 ` Alex Kotenko 2014-03-22 16:35 ` Jeff Garzik 0 siblings, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-03-21 13:59 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1288 bytes --] 2014-03-21 10:28 GMT+00:00 Andreas Schildbach <andreas@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 > [-- Attachment #2: Type: text/html, Size: 2794 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 13:59 ` Alex Kotenko @ 2014-03-22 16:35 ` Jeff Garzik 2014-03-22 16:45 ` Mike Hearn 2014-03-22 16:55 ` Mark Friedenbach 0 siblings, 2 replies; 69+ messages in thread From: Jeff Garzik @ 2014-03-22 16:35 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Andreas Schildbach 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 <alexykot@gmail•com> wrote: > 2014-03-21 10:28 GMT+00:00 Andreas Schildbach <andreas@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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-22 16:35 ` Jeff Garzik @ 2014-03-22 16:45 ` Mike Hearn 2014-03-22 16:55 ` Mark Friedenbach 1 sibling, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-22 16:45 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 400 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 639 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-22 16:35 ` Jeff Garzik 2014-03-22 16:45 ` Mike Hearn @ 2014-03-22 16:55 ` Mark Friedenbach 2014-03-22 17:24 ` Jeff Garzik 1 sibling, 1 reply; 69+ messages in thread From: Mark Friedenbach @ 2014-03-22 16:55 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-22 16:55 ` Mark Friedenbach @ 2014-03-22 17:24 ` Jeff Garzik 2014-03-22 17:30 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Jeff Garzik @ 2014-03-22 17:24 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev 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 <mark@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/ ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-22 17:24 ` Jeff Garzik @ 2014-03-22 17:30 ` Mike Hearn 2014-03-23 3:47 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-22 17:30 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2787 bytes --] 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 <jgarzik@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 <mark@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 > [-- Attachment #2: Type: text/html, Size: 4063 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-22 17:30 ` Mike Hearn @ 2014-03-23 3:47 ` Alex Kotenko 0 siblings, 0 replies; 69+ messages in thread From: Alex Kotenko @ 2014-03-23 3:47 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1223 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 2247 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 12:12 ` Adam Back 2014-03-20 12:20 ` Mike Hearn 2014-03-20 17:31 ` Jeff Garzik @ 2014-03-21 10:25 ` Andreas Schildbach 2014-03-21 10:59 ` Adam Back 2 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 10:25 UTC (permalink / raw) To: bitcoin-development 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?). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 10:25 ` Andreas Schildbach @ 2014-03-21 10:59 ` Adam Back 2014-03-21 11:08 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Adam Back @ 2014-03-21 10:59 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development 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?). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 10:59 ` Adam Back @ 2014-03-21 11:08 ` Mike Hearn 2014-03-21 11:33 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-21 11:08 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1607 bytes --] On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@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. [-- Attachment #2: Type: text/html, Size: 2454 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 11:08 ` Mike Hearn @ 2014-03-21 11:33 ` Mike Hearn 2014-03-21 12:25 ` Adam Back 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-21 11:33 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 1954 bytes --] 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 <mike@plan99•net> wrote: > On Fri, Mar 21, 2014 at 11:59 AM, Adam Back <adam@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. > [-- Attachment #2: Type: text/html, Size: 3114 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 11:33 ` Mike Hearn @ 2014-03-21 12:25 ` Adam Back 2014-03-21 13:07 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Adam Back @ 2014-03-21 12:25 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 12:25 ` Adam Back @ 2014-03-21 13:07 ` Mike Hearn 0 siblings, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-21 13:07 UTC (permalink / raw) To: Adam Back; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 871 bytes --] 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 <adam@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. >> > [-- Attachment #2: Type: text/html, Size: 1593 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 10:36 ` Mike Hearn 2014-03-20 12:12 ` Adam Back @ 2014-03-20 18:20 ` Alex Kotenko 2014-03-20 18:31 ` Mike Hearn 1 sibling, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-03-20 18:20 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 2248 bytes --] 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 <mike@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 > > [-- Attachment #2: Type: text/html, Size: 3340 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 18:20 ` Alex Kotenko @ 2014-03-20 18:31 ` Mike Hearn 2014-03-20 18:50 ` Alex Kotenko 2014-03-20 21:52 ` Roy Badami 0 siblings, 2 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-20 18:31 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 3048 bytes --] 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 <alexykot@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 <mike@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 >> >> > [-- Attachment #2: Type: text/html, Size: 4519 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 18:31 ` Mike Hearn @ 2014-03-20 18:50 ` Alex Kotenko 2014-03-20 21:52 ` Roy Badami 1 sibling, 0 replies; 69+ messages in thread From: Alex Kotenko @ 2014-03-20 18:50 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 3687 bytes --] 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 <mike@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 <alexykot@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 <mike@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 >>> >>> >> > [-- Attachment #2: Type: text/html, Size: 5654 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 18:31 ` Mike Hearn 2014-03-20 18:50 ` Alex Kotenko @ 2014-03-20 21:52 ` Roy Badami 2014-03-20 23:02 ` Mike Hearn 2014-03-21 10:43 ` Andreas Schildbach 1 sibling, 2 replies; 69+ messages in thread From: Roy Badami @ 2014-03-20 21:52 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 21:52 ` Roy Badami @ 2014-03-20 23:02 ` Mike Hearn 2014-03-26 22:48 ` Roy Badami 2014-03-21 10:43 ` Andreas Schildbach 1 sibling, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-20 23:02 UTC (permalink / raw) To: Roy Badami; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 449 bytes --] > > 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. However remember that signing in BIP70 is about more than just security, though that's the driving factor. It's also needed for things like dispute mediation, receipts, etc. [-- Attachment #2: Type: text/html, Size: 719 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 23:02 ` Mike Hearn @ 2014-03-26 22:48 ` Roy Badami 2014-03-26 22:56 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Roy Badami @ 2014-03-26 22:48 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-26 22:48 ` Roy Badami @ 2014-03-26 22:56 ` Mike Hearn 2014-03-26 23:20 ` Andreas Schildbach 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-26 22:56 UTC (permalink / raw) To: Roy Badami; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 131 bytes --] Yeah, for those cases we'd need to think of something else. That gets into the realm of creating our own infrastructure though ... [-- Attachment #2: Type: text/html, Size: 187 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-26 22:56 ` Mike Hearn @ 2014-03-26 23:20 ` Andreas Schildbach 2014-03-27 10:08 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-26 23:20 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-26 23:20 ` Andreas Schildbach @ 2014-03-27 10:08 ` Mike Hearn 2014-03-27 13:31 ` vv01f 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-03-27 10:08 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1973 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 2679 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-27 10:08 ` Mike Hearn @ 2014-03-27 13:31 ` vv01f 2014-06-30 19:26 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: vv01f @ 2014-03-27 13:31 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2638 bytes --] 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 <mike@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 [-- Attachment #2: Type: text/html, Size: 3741 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-27 13:31 ` vv01f @ 2014-06-30 19:26 ` Alex Kotenko 2014-07-01 8:18 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-06-30 19:26 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4710 bytes --] 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_address>&rbt=bt:<BT_MAC_addres>). 2. allow multiple "r" parameters (e.g. r=http://<web_address>&r=bt:<BT_MAC_addres>). 3. allow "r" to be an array (e.g. r%5B0%5D=http://<web_address>&r%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 <vv01f@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 <mike@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 > > [-- Attachment #2: Type: text/html, Size: 8553 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-06-30 19:26 ` Alex Kotenko @ 2014-07-01 8:18 ` Mike Hearn 2014-07-01 9:48 ` Andreas Schildbach 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-07-01 8:18 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1108 bytes --] > > 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 :/ [-- Attachment #2: Type: text/html, Size: 1508 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 8:18 ` Mike Hearn @ 2014-07-01 9:48 ` Andreas Schildbach 2014-07-01 10:42 ` Michael Wozniak 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-07-01 9:48 UTC (permalink / raw) To: bitcoin-development 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.) ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 9:48 ` Andreas Schildbach @ 2014-07-01 10:42 ` Michael Wozniak 2014-07-01 13:03 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Michael Wozniak @ 2014-07-01 10:42 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development 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 <andreas@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 10:42 ` Michael Wozniak @ 2014-07-01 13:03 ` Alex Kotenko 2014-07-01 14:59 ` Andreas Schildbach 0 siblings, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-07-01 13:03 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1890 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 3708 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 13:03 ` Alex Kotenko @ 2014-07-01 14:59 ` Andreas Schildbach 2014-07-01 15:07 ` Michael Wozniak 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-07-01 14:59 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 14:59 ` Andreas Schildbach @ 2014-07-01 15:07 ` Michael Wozniak 2014-07-01 15:39 ` Andreas Schildbach 0 siblings, 1 reply; 69+ messages in thread From: Michael Wozniak @ 2014-07-01 15:07 UTC (permalink / raw) To: Andreas Schildbach; +Cc: bitcoin-development 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 <andreas@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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 15:07 ` Michael Wozniak @ 2014-07-01 15:39 ` Andreas Schildbach 2014-07-01 17:18 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-07-01 15:39 UTC (permalink / raw) To: bitcoin-development 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 <andreas@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 > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 15:39 ` Andreas Schildbach @ 2014-07-01 17:18 ` Alex Kotenko 2014-07-01 17:59 ` Mike Hearn 0 siblings, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-07-01 17:18 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 6770 bytes --] 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" <andreas@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 <andreas@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 > > > > > > > ------------------------------------------------------------------------------ > 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 > [-- Attachment #2: Type: text/html, Size: 9042 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 17:18 ` Alex Kotenko @ 2014-07-01 17:59 ` Mike Hearn 2014-07-02 8:49 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Mike Hearn @ 2014-07-01 17:59 UTC (permalink / raw) To: Alex Kotenko; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 124 bytes --] Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect that escaping is largely unnecessary in many cases. [-- Attachment #2: Type: text/html, Size: 247 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-07-01 17:59 ` Mike Hearn @ 2014-07-02 8:49 ` Alex Kotenko 0 siblings, 0 replies; 69+ messages in thread From: Alex Kotenko @ 2014-07-02 8:49 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev, Andreas Schildbach [-- Attachment #1: Type: text/plain, Size: 485 bytes --] 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 <mike@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. > > > [-- Attachment #2: Type: text/html, Size: 1305 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 21:52 ` Roy Badami 2014-03-20 23:02 ` Mike Hearn @ 2014-03-21 10:43 ` Andreas Schildbach 1 sibling, 0 replies; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 10:43 UTC (permalink / raw) To: bitcoin-development +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 > ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 2:22 ` Alex Kotenko 2014-03-20 3:31 ` Jeff Garzik @ 2014-03-20 8:08 ` Andreas Schildbach 2014-03-20 16:14 ` Alex Kotenko 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-20 8:08 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 8:08 ` Andreas Schildbach @ 2014-03-20 16:14 ` Alex Kotenko 2014-03-21 9:47 ` Andreas Schildbach 0 siblings, 1 reply; 69+ messages in thread From: Alex Kotenko @ 2014-03-20 16:14 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5183 bytes --] 2014-03-20 8:08 GMT+00:00 Andreas Schildbach <andreas@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 > [-- Attachment #2: Type: text/html, Size: 8340 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-20 16:14 ` Alex Kotenko @ 2014-03-21 9:47 ` Andreas Schildbach 2014-03-21 13:54 ` Alex Kotenko 0 siblings, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 9:47 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 9:47 ` Andreas Schildbach @ 2014-03-21 13:54 ` Alex Kotenko 2014-03-21 14:51 ` Andreas Schildbach 2014-03-21 15:20 ` Andreas Schildbach 0 siblings, 2 replies; 69+ messages in thread From: Alex Kotenko @ 2014-03-21 13:54 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3740 bytes --] 2014-03-21 9:47 GMT+00:00 Andreas Schildbach <andreas@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 > [-- Attachment #2: Type: text/html, Size: 5649 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 13:54 ` Alex Kotenko @ 2014-03-21 14:51 ` Andreas Schildbach 2014-03-21 15:38 ` Alex Kotenko 2014-03-21 15:20 ` Andreas Schildbach 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 14:51 UTC (permalink / raw) To: bitcoin-development > > 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. Quoting from RFC 3986, Section 3.4. Query: "The characters slash ("/") and question mark ("?") may represent data within the query component." > 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. Thanks for testing this. It would be interesting to know what device and software you used for scanning. But anyway, it falls into the same ballpark as my tests. > 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. So BIP72 with a BT URI in the 'r' parameter? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 14:51 ` Andreas Schildbach @ 2014-03-21 15:38 ` Alex Kotenko 0 siblings, 0 replies; 69+ messages in thread From: Alex Kotenko @ 2014-03-21 15:38 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 303 bytes --] 2014-03-21 14:51 GMT+00:00 Andreas Schildbach <andreas@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. [-- Attachment #2: Type: text/html, Size: 1072 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 13:54 ` Alex Kotenko 2014-03-21 14:51 ` Andreas Schildbach @ 2014-03-21 15:20 ` Andreas Schildbach 2014-03-21 15:24 ` Mike Hearn 1 sibling, 1 reply; 69+ messages in thread From: Andreas Schildbach @ 2014-03-21 15:20 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments 2014-03-21 15:20 ` Andreas Schildbach @ 2014-03-21 15:24 ` Mike Hearn 0 siblings, 0 replies; 69+ messages in thread From: Mike Hearn @ 2014-03-21 15:24 UTC (permalink / raw) To: Andreas Schildbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1849 bytes --] 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 <andreas@schildbach•de>wrote: > 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 > [-- Attachment #2: Type: text/html, Size: 2587 bytes --] ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2014-07-02 8:49 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-27 11:59 [Bitcoin-development] Payment Protocol for Face-to-face Payments Andreas Schildbach 2014-01-27 13:11 ` Mike Hearn 2014-01-27 18:18 ` Andreas Schildbach 2014-01-27 18:34 ` Mike Hearn 2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach 2014-01-27 21:47 ` Mike Hearn 2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman 2014-01-27 17:39 ` Andreas Schildbach 2014-01-27 18:18 ` Jeremy Spilman 2014-01-27 20:34 ` Roy Badami 2014-01-29 14:57 ` Christophe Biocca 2014-01-30 10:46 ` Andreas Schildbach 2014-01-30 10:50 ` Mike Hearn 2014-02-07 23:15 ` Andreas Schildbach 2014-03-02 9:47 ` Andreas Schildbach 2014-03-02 11:50 ` Mike Hearn 2014-03-20 2:22 ` Alex Kotenko 2014-03-20 3:31 ` Jeff Garzik 2014-03-20 8:09 ` Andreas Schildbach 2014-03-20 10:36 ` Mike Hearn 2014-03-20 12:12 ` Adam Back 2014-03-20 12:20 ` Mike Hearn 2014-03-20 17:31 ` Jeff Garzik 2014-03-20 17:42 ` Alex Kotenko 2014-03-20 18:01 ` Jeff Garzik 2014-03-21 10:28 ` Andreas Schildbach 2014-03-21 13:59 ` Alex Kotenko 2014-03-22 16:35 ` Jeff Garzik 2014-03-22 16:45 ` Mike Hearn 2014-03-22 16:55 ` Mark Friedenbach 2014-03-22 17:24 ` Jeff Garzik 2014-03-22 17:30 ` Mike Hearn 2014-03-23 3:47 ` Alex Kotenko 2014-03-21 10:25 ` Andreas Schildbach 2014-03-21 10:59 ` Adam Back 2014-03-21 11:08 ` Mike Hearn 2014-03-21 11:33 ` Mike Hearn 2014-03-21 12:25 ` Adam Back 2014-03-21 13:07 ` Mike Hearn 2014-03-20 18:20 ` Alex Kotenko 2014-03-20 18:31 ` Mike Hearn 2014-03-20 18:50 ` Alex Kotenko 2014-03-20 21:52 ` Roy Badami 2014-03-20 23:02 ` Mike Hearn 2014-03-26 22:48 ` Roy Badami 2014-03-26 22:56 ` Mike Hearn 2014-03-26 23:20 ` Andreas Schildbach 2014-03-27 10:08 ` Mike Hearn 2014-03-27 13:31 ` vv01f 2014-06-30 19:26 ` Alex Kotenko 2014-07-01 8:18 ` Mike Hearn 2014-07-01 9:48 ` Andreas Schildbach 2014-07-01 10:42 ` Michael Wozniak 2014-07-01 13:03 ` Alex Kotenko 2014-07-01 14:59 ` Andreas Schildbach 2014-07-01 15:07 ` Michael Wozniak 2014-07-01 15:39 ` Andreas Schildbach 2014-07-01 17:18 ` Alex Kotenko 2014-07-01 17:59 ` Mike Hearn 2014-07-02 8:49 ` Alex Kotenko 2014-03-21 10:43 ` Andreas Schildbach 2014-03-20 8:08 ` Andreas Schildbach 2014-03-20 16:14 ` Alex Kotenko 2014-03-21 9:47 ` Andreas Schildbach 2014-03-21 13:54 ` Alex Kotenko 2014-03-21 14:51 ` Andreas Schildbach 2014-03-21 15:38 ` Alex Kotenko 2014-03-21 15:20 ` Andreas Schildbach 2014-03-21 15:24 ` Mike Hearn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox