Electron-cash: need to unify QR codes

[markblundeberg]

The receive tab and address dialog make quite different QR codes for the same address.

• Receive tab QR encodes: BITCOINCASH:QR8ZT8NCV94RSNC0LFKUJ3QVDZU2JTY2ASQ44CJHKU
• Address tab QR encodes: qr8zt8ncv94rsnc0lfkuj3qvdzu2jty2asq44cjhku

Both QR codes end up as the same size because, even though the first one is longer, it uses all-uppercase which lets it use the compact QR alphanumeric encoding. I believe the prefix is a good idea in general, so I am leaning towards the prefixed, all-caps option.

(the reason for the difference: address_detail.py uses to_ui_string(), and main_window.py receive tab uses the update_receive_qr() function which does more things)

[imaginaryusername]

I was going to suggest "why not all uppercase without prefix", then tested and realized no wallet scans that.

The latter (no prefix, lowercase) actually would offer slightly more compatibility since the schildbach fork (https://github.com/bitcoincash-wallet/bitcoincash-wallet) doesn't scan uppercase - but I also agree that prefix is a good idea if more generalized scanners implement it in the future...

After thinking for a bit, one vote for prefix+uppercase.

[jhoenicke]

Definitely always add the prefix to the qr-code as it is part of the address. It would be very cumbersome if every multi-crypto wallet would need to add all known prefixes (bchtest:, bitcoincash:, bc1, ltc1, ...) and check for which the checksum matches just to determine what kind of address was provided :)

Also some qr-code scanner can use this prefix to find the application that should handle the address.

[cculianu]

I'm all for going over to the bitcoincash: - style...

Just curious -- why does it matter if it's a more compact encoding, really?

[imaginaryusername]

More compact QRs are "easier" to scan in my experience (they do better if resized, have wider tolerance at being scanned from distance or out of focus, etc). Don't know if there are robust research backing it.

[cculianu]

Ah, makes sense. I imagine they would be.

Although honestly I'm amazed at how good QR already is and how well it works even when it's dense and packed with info and the squares are small. (like has a huge long URL or something). I have never been unable to scan a QR code ever. But maybe i'm just lucky...

[markblundeberg]

@cculianu I have only failed scanning QR codes when I am trying to take Roger Ver's money. Probably has to do with the fuzziness and angle, but I can't get a scan.

Speaking of which, the bitcoin.com wallet's QR codes for addresses are a third type: prefixed and lowercased. They are significantly larger not just because of this but also they use the second-highest error correction level possible (then slap their logo in the middle)

For example this last one has the same size and format as:

[cculianu]

@markblundeberg Hahahaha. Did you actually stand a chance of getting that money? Hilarious.

Didn't realize there are various ECC options for QR. Maybe we can see if the lib we use can do better?

Well -- i can easily change the Qt code to generate whatever. So I guess the consensus is all screens do BITCOINCASH:QQBLABLA (all uppercase)??