Consider Using URs? + UR for bitcoin air gapped already supports animated QRs

[ChristopherA]

Has this community considered moving over the QR's using the UR-based encoding, which among other things is optimized for native-QR compression and already supports animated QRs? This standard is for more than just PSBTs (Sparrow, Keystone, Foundation Devices, Spectre, etc.), but also since it uses self-describing CBOR underneath, can be used for seeds, keys derivations, etc. It would not be hard to add any BIP21 primitives.

See https://github.com/BlockchainCommons/crypto-commons#urs for a number of overview documents and a video on the UR standards.

[FoundationKen]

The animated QR codes make the QR code size much less of an issue. Would also just be great to standardize on a single animated QR code format. UR is well-documented, and is already in use in several popular wallets as Christopher mentioned.

[sbddesign]

Help me understand. What is the benefit of a "UR" over a BIP21 URI?

[ChristopherA]

The UR specifications and reference code have many advantages:

• They are designed to be fully conformant with URI schemes (e.g. https:, mailto:, etc.) so that platforms can send the QR (or NFC) to apps registering to handle UR: scheme requests.
• There are some inconsistencies in character set usage of many URIs, especially in legacy Bitcoin QRs, etc. that often result in double the size of the QR (as it goes into "binary" mode). The UR specifications are specifically designed to be optimally compressed by QR encoders to be quite small.
• Many messages encoded in QRs (in particular PSBTs) exceed the ability for many devices to accurately read them (especially with cheap laptop cameras) or even exceed what is possible with a QR. All the UR libraries support animated QRs, which include fountain codes for redundancy in case a frame is missed. There are short of a dozen bitcoin wallet vendors already supporting crypto-psbt URs, and there are multiple versions in other languages (are reference version is in C).
• URs are completely self-describing, both in what humans need (i.e. "ur:crypto-psbt") as well as CBOR for the content. This means that metadata like account birthdate, which the Lightning Network can use to reduce blockchain scanning time, can be optionally included and optionally ignored by services that don't need it. This is particularly relevant to some of the BIP21 use cases as not all apps need the same data.
• As a community, we can afford to fund security reviews of critical code collectively, as we recently did with the SSKR cryptography. We will be doing this for more of a critical code in 2022.
• There are a number of new URs either in the process of being designed, or on the roadmap, including crypto-response & crypto-request (see new article: https://github.com/BlockchainCommons/crypto-commons/blob/master/Docs/crypto-request-or-crypto-psbt.md); encryption of data in QRs with symmetric pins, keys or public key permits; authorization for access using your keys (Wallet Connect style, but more secure);, initiating Musig2 & FROST group signatures; and much more.

To date, we don't have many Lightning developers submitting UR specs for LN use cases. We'd love to see more here, including to support BIP21.

[wolfmcnally]

Help me understand. What is the benefit of a "UR" over a BIP21 URI?

The UR spec actually lays out the benefits:

• Transport binary data of arbitrary content and length using a sequence of one or more URIs or QR codes.
• Remain agnostic about whether QR codes are displayed together or time-sequenced (animated).
• Avoid the use of QR code binary mode to support transparency and wide compatibility with QR code reader libraries.
• Use the alphanumeric QR code mode for efficiency.
• Be case agnostic, allowing use of all upper case letters (for QR code transport) or all lower case letters (canonical for display and URIs.)
• Include a CRC32 checksum of the entire message in each part to tie them together and ensure the transmitted message has been reconstructed.
• Each single part should also be a valid URI and not require escaping (e.g. percent-encoding) of any of its characters.
• Support the addition of structure in the binary data using CBOR.
• Support transmitting an arbitrary amount of data both as a minimal, finite sequence of parts and as an indefinite sequence of parts using a "rateless encoding" Fountain Code based on Luby Transform code.

[wolfmcnally]

I'd also recommend our Blockchain Commons Technology Overview video that discusses the building blocks we're working with and our motivations for choosing or building them.

[ChristopherA]

We also have experimental support of NFCs on the iPhone in our demo reference app Gordian Seed Tool. This means you can tap a merchant's device, and it will call the app using a ur: scheme. The current BIP21 proposal is not directly compatible with NFCs, as platforms require that they must be strictly URI conformant (which the UR specs are).

[moneyball]

Can you help us understand what actually needs to happen to support this? Does every wallet showing a QR code today need to change to support UR? What does that entail?

[wolfmcnally]

Can you help us understand what actually needs to happen to support this? Does every wallet showing a QR code today need to change to support UR? What does that entail?

Obviously, the more developers and wallets that adopt the UR specification, the greater the network effect of adoption. Blockchain Commons is trying to help wallet developers interoperate and avoid having to reinvent the wheel where it would benefit the entire community. There are already open source libraries to support UR in several languages, so adoption should be pretty easy in most cases.

[sbddesign]

I will need to take more time to dig into your spec here. I'm genuinely curious to learn about it, so thank you for sharing.

A large part of BIP21 for us is that it already enjoys widespread support among most on-chain wallets, and is gaining support among lightning wallets. For wallets like Strike, CashApp, Bitcoin Beach, etc. this can be a very quick fix for their UX.

While I see the value of a standardized format like this for things like animated QRs for PSBTs, the BIP21 for lightning seems like really low-hanging fruit that lightning wallets can start benefiting from in the very near future.

So I am going to close this issue, but I will re-open it if we need to start pursuing the animated QRs in more depth. I am not closed off to this idea, I just see it being more beneficial for other use cases, whereas this initiative is very much focused on the bitcoin-on-chain/lightning UX problem.