coinkite / bbqr Goto Github PK

As descriptor need to be share between wallets/coordinators and airgapped signers in miniscript setups, it should be useful to have a Type for standalone descriptor, at least used at the initial descriptor registration step.

As requested, my feedback. It's difficult to consider this without comparing against the dominant BC-UR standard. The major advantage compared to BC-UR seems to be the simplicity of the scheme. However, there are several drawbacks:

• The efficiency of an animated QR scheme should not be measured in the minimum number of QRs required in the sequence, but the number of QRs that constitute a successful data transfer in practice. It is common when scanning that some QRs in a sequence are missed, due to movement of the hand holding the display device, differences in display and scan rates etc. This scheme does not use fountain codes, and thus any missed QRs means total number of QRs in the sequence must be scanned again.
• The maximum number of QRs is limited to 255 in the sequence, which means on version 21 a maximum transfer size of 270810 bytes. I have just created a segwit PSBT with 100 inputs at 272k. Even if compression would make this particular transfer possible, it seems too low a limit to cater for all situations. Consider further the need to include the entire previous transaction in the PSBT non-witness field for legacy script UTXOs, and some hardware wallets that require both the non-witness and witness fields regardless!
• "Your software would need to be pretty dumb to accept a PSBT file when it was expecting a list of seed words!" Many interfaces, especially mobile ones, use a global/general purpose QR scanning interface element, for example on the top left of the wallet application home screen. If the type of the data that has been scanned cannot easily be determined, the content must be guessed at ala mimemagic. Even with a more specific interface element, the type of the data expected must be specified upfront, rather than reacted to. This is inherently less flexible and puts more burden on the scanning application. IMO well defined types should always be preferred in communication protocols.
• The current specification restricts itself to types which already have a well-defined data structure, like transactions and PSBTs. Other types like seed words, output descriptors, message signing parameters and xpub exports are less well defined. Without any standards for these, developers are likely to invent their own resulting in reduced compatibility, and more headaches for coordinator wallets that must support an ever-changing variety of possible formats.

BC-UR does not have these drawbacks, so they must be weighed against the simplicity of implementation. I can't speak knowledgeably to the capability of embedded devices, but certainly it has been possible for many hardware wallet implementors to send and receive BC-UR formatted QRs.

Further, this adds another QR standard. While it is simple to add support for scanning this format, with BC-UR already well established the choice of which standard to use when displaying an animated sequence must probably be left to the user, burdening them with a technical detail they are unlikely to understand. There should be a very good reason to have to put in the effort of educating an entire userbase, and adding this additional complexity to the UX flow of many common operations.

Both Android and iOs are able to automatically open the right (or the wrong…) app when you scan a QR with the OS camera app.

At least with Apple, developers can register their app to use whatever prefix they want (afaik).

You could either pick one prefix, that's not already in use, like bbqr:. Alternatively pick one per data type, so it's less likely the wrong app is opened. Or completely leave it open for devs to fight over, but just allow it.

This is mainly useful for single codes, not so much when handling multiple "pages". This is because the first QR would open the app, after which the app will have to initiate scanning the next one, and a URI prefix isn't needed.

Version 27 (125 x 125 pixels) offers up to 1062 bytes of useful payload per QR, so it is a good sweet spot to consider. A simple implementation would split file into 1k (1024) blocks, with one runt, and can be sure that verison 27 QR will hold all the blocks.

Since the typical Bitcoin wire transaction is less than 500 bytes, most finalized transactions will be encoded in a single QR with no header or other overhead needed.

In the example:

All but final QR holds 1000 bytes when decoded, and will be 2007 characters in length.

I suggest to allow padding the last QR. Since the data length is not encoded, you can't use zeros for this padding, but any character that's part of the set 0-9A-Z$%*+-./:, and not part of hex (0-9A-F) and bech32 can be used. I.e. IO$%*+-./:. My suggestion would be ., because it keeps things human readable. (I suggest in any case not using I or O because that makes a future "lazy just do plain alphanumeric text" standard impossible.)

This makes life easier for UI developers: they can just format their layout for a 125 x 125 QR code. The last image won't look weird, without having to do math to figure out the right size. And a consistent size for every transaction is nice for users in general.