7kb for a supermarket bill is plenty, and you can have several of them.

Forms and legal documents should all have an immutable official url and uuid anyway to point to their legal and administrative context.

The largest QR code in the standard, "version 40" - can only store 3 kilobytes at the lowest level of error correction and 1.2 kilobytes at the highest level [1]. And that's a pretty huge QR code [2]

My back-of-the-envelope calculations say you'd need 61 bits per line on a receipt just to encode UPC, quantity and price. So the largest QR code would only allow 19-50 lines. And that's without including data like the store name, special offers, means of payment and so on. Believe me, plenty of people buy more than 50 items in their supermarket christmas shop :)

Standardised digital receipts would be neat but, QR codes encoding the data ain't the way to go about it.

[1] https://www.qrcode.com/en/about/version.html [2] https://commons.wikimedia.org/wiki/File:Qr-code-ver-40.svg

Seems like the obvious thing would be to have the QR code contain a "receipt ID" (UUID?) in a URL.

When the QR code is scanned, the browser opens to the URL, the remote side takes your "receipt ID", and presents you with a list of all the items you purchased.

I can't imagine any decent-sized retailer isn't already maintaining records like this.

See, one of the useful properties of a paper receipt is that, once you receive it, you can be fairly confident about the ~one way you're going to lose it

Two ways. Receipts fade, sometimes very quickly.

1.2 kilobytes = 9.6 kilobits. If you need 61 bits per line, you’ve got enough bits for 157 lines. 393 lines if we go with 3 kilobytes. I think you may have used 61 bytes per line in your calculation rather than 61 bits.

I (not OP) would say bytes would be closer. The product name could be 20 characters long (20 bytes minimum)

OP was assuming the receipt would list the product UPC code rather than product name. A UPC code is 12 digits, which can be encoded in 40 bits.

it could just contain a url linking to a page with to content.

I wish we could encode PGP public keys with them, but it's still too much data.

That would be a neat way of exchanging a key.

You can definitely encode ed25519 keys to a QR code.

How big is your pgp public key? Mine is under 4K in ascii and can definitely fit in a QR code.

If you use a crypto atm it will print out your wallet’s private and sometimes public keys as QR codes.

4K is around the point where some devices will start to have issues scanning. Also, crypto wallets won’t usually give you the private key, instead they’ll give you the 12 word BIP39 seed phrase which will be around 70-80 bytes.

Gpg key fingerprints are very small though and can be used for that.

Can X.509 ceros use elliptic curve? They’d be much smaller.

Even without the key they start to look pretty dense. You can definitely fit one in a QR code, they just start to become less reliable to scan (especially on cheap devices), and they go from looking nice to looking quite ugly. Technically most X.509 certs would have been within the limitations of QR codes (though I don’t think there is an upper bound to how large they can get), but I realized it just wasn’t fit for purpose and moved on to something else.

Are you using 8 bit encoding? An alphanumeric mode QR code containing base 64 encoded data provides less capacity. In binary mode even a 4096 bit RSA secret key fits while ECC keys produce smaller codes.

The qrencode tool has an 8 bit mode but not all decoders can handle binary data. For example, my phone shows me mangled results and I can't redirect them to a file. Like structured append, it doesn't seem to have much support.

I've sent patches to ZBar improving this:

https://github.com/mchehab/zbar/pull/64

Hopefully it will make QR codes more useful for storing keys and other small files.

i think datamatrix is more suitable for x509

Yes.. I had made a form that was scanned and all the metadata for the page was stored in datamatrix at the bottom.. With a laser printer and a good scanner you can reliably put a lot of data in there...