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.