pull down to refresh

I was looking at a lightning invoice screen in the Zeus wallet. The invoice QR code is above the text coded (is this base64 or some other format?) invoice. What I notice is that the text coded invoice is actually smaller than the QR code. That got me thinking. The character recognition technology is advanced enough so that the actual text representation can be scanned (especially if it is shown in a font optimized for character recognition). The character representation can more easily be compared by human if needed than a qr code (yeah, i know that random characters are not that easily for comparison, but it is definitely easier than comparing qr codes).
So why is the invoice (or even a btc onchain address which is even smaller) represented by a qr code instead of a text in a machine readable font?
113 sats \ 0 replies \ @freetx 6 Jun
Thats a good point.
I think the one benefit QR Code has is its compact 2D nature. Having a "1D" Linear line of of text makes presentation more difficult - as it requires more space.
Having said that, I suppose you could also just display the text in a 2D grid of 40x40 chars (or whatever)
reply
Nice find. Would certainly be nice to obfuscate some of the QR overload of recent years. And it definitely feels like a stop-gap solution to future digital life.
Separate topic - part of the experience is improved because a QR is quite clearly distinguishable from our language or a picture or other means of communication. There are definitely use cases to hiding invoice QRs from plain sight, but I suspect any new standard would still need to be 'visible' so as to ensure backwards compatibility and to ensure people/machines are actively wishing to engage with it. Not accidentally triggering or actioning requests. Otherwise our lives would be DDOS'd with payment requests.
reply
I am not sure about the second part. This is not a regular text, it's a bunch of characters. It can be put in a square (with fixed width font) so that it is obvious it is intended to be scanned. Also you usually need to actively engage the scan functionality. No way to accidently scan anything.
I am also thinking about using some identicon logic to put some color scheme on the characters themselves, so that human comparison can become very easy.
reply
21 sats \ 0 replies \ @k00b 6 Jun
That's an excellent insight!
I don't think OCR is as widely available and accessible as QR code readers, and it probably wouldn't work too well on cheap devices. I could see this happening at some point though.
Bech32 should also allow detection of most reading errors.
reply
126 sats \ 3 replies \ @om 6 Jun
the text coded invoice is actually smaller than the QR code
The QR code isn't necessarily shown in the smallest size it can be while still being recognizable. I'd guess it's the opposite: it's shown the largest it can be.
The QR code involves an error correcting code (Reed-Solomon) which can eat about half the area (depends on the settings with which the code was produced). So double your text area to accomodate the error correcting codes.
Once you do that, I believe that the QR code would actually win in efficiency in terms of size. That doesn't mean that you can't use letters if you want the thing to be human-readable, but for invoices it would be a whole lot of letters.
reply
0 sats \ 2 replies \ @joda 6 Jun
yeah this. Depending on your chosen error correction, you could have a year-old smudged and ripped QR code still scan. If you smudge even a single letter of text, forget about it.
reply
OK, but is this really an advantage for this use case? Here the invoice is displayed on a screen and there is no way for it to degrade in that way.
reply
0 sats \ 0 replies \ @joda 8 Jun
also there are letters and numbers that are visually ambiguous (1/l, 0/O, etc). In binary and with error correction it's easy.
QR can also be animated, allowing for a huge amount of data.
wish I could find a cool article I read a year or so back, but the wikipedia page is pretty interesting too:
reply