Fixed focal length camera vs QR code size & Other UR Requirements?

[BitcoinLixin]

Original post cryptoadvance/specter-desktop#374

When we were making Cobo Vault, we did some test on fixed focal length camera VS auto focus camera.

The scanning speed of fixed focal length camera is over twice faster than auto focus camera - an auto focus camera will redo focus procedure when it sees a new QR code and in the scenario of animated QR code, it takes much more time than fixed focal length camera.

But the fixed focal length cause another problem - it can only read the QR code in a specific range of actual size. This is not a big problem if the user is using mobile companion app. But if the user is using a desktop software wallet like Specter, as the PPI varies a lot between different monitors, it better to add a slide bar on wallet for user to manually adjust the actual size of the QR code.

It would be better if the size can be memorized so the users don't need to adjust every time.

[ChristopherA]

/cc: @gorazdko

[gorazdko]

I think these kinds of things should be part of the UR standard/spec, e.g. in section Integration Guidelines.

A related problem could occur on hw devices if the qr code is too dense for a certain scanner of lower resolution capabilities. In that case, animated option should be supported.

For now I'd just put a label on the issue [spec][todo]

[ChristopherA]

FFI, some items related to this topic:

• One milestone @gorazdko is focusing on during this cycle (ending end of October) is to identify the speed of which the paper display on the LetheKit v0 can be driven for reliable output to a low-end iPhone. The paper display is 200x200, which means I think 178x178 1-px per QR pixel sized QRs. But this may be too small and we'll have to go to a smaller HxW at 4px per QR. Some questions are not only how fast, but what level of redundancy (as animated URs already have a CRC) but also whether he has to wipe the paper display to blank between each frame for it to reliably transfer. I consider what he discovers will be a possible bottom baseline an animated QR display.

• @jlopp brings up the topic of large PSBTs, maybe even as large is 1MB (https://twitter.com/lopp/status/1304810084095139840?s=20 and my reply). When @wolfmcnally returns to his UR Demo app & library to help @Fonta1n3 add full animated QR support to Gordian Wallet this cycle, I'm hoping we can understand this side of the problem more. How fast can a reasonably current mobile phone reliably transfer at 1MB PSBT? And what really is a more realistic multisig PSBT size going to be?

• Another milestone for @gorazdko which may be after October, is to identify camera options for the LetheKit v1. @ksedgwic has identified in the past with a different DIY box for BaseZero that tis may mean that adding that non-fixed focus camera to the LetheKit would also require a much higher quality screen as you need to see it on the screen to see if focus is correct. I've love for him to also consider a fixed-focus camera option that would work with the Arduino. @BitcoinLixin if you know of any for him to look at, it would be appreciated.

• And of course, we ought to be making test tools for other airgap vendors, such @stepansnigirev's Spectre, to evaluate their min/max size big/small length UR limitations, and collectively offer recommendations on ideal ranges for max compatibility and yet as conventient for the user as reasonable.

Let me know if there are any other topics that we should be research as we prepare a more formal WIP (Wallet Improvement Proposal for possible submission as a BIP) to describe it.

-- Christopher Allen

[jlopp]

Just to add a bit of real-world practicality: many of our clients keep a signing device like a coldcard in a safety deposit box and their access to this box is time constrained such that having to spend 20+ minutes inside of a private vault to sign a transaction is untenable.

[wolfmcnally]

I did some experimentation with URDemo and a 1MB UR payload. I chose a 500b max fragment size. The payload took 24 minutes to transfer from an iPad Pro to an iPhone X, for a throughput of 695b/sec. Obviously I didn't design the algorithm to handle such large payloads, and the main thing I noticed was a degradation in frame rate after the initial pass through all 2000 individual fragments, owing to the fountain code algorithm that selects a random mix of fragments to include in each part. It appears that parts that include many fragments take longer, and this makes sense given the need to XOR all those parts together; a lot of the sub-algorithms used have complexity linear to the number of selected fragments for a part. To ensure the problem wasn't in my UI, I turned off the "fragment bar" in both the sender and receiver.

There may be ways to optimize the code to create a steady, fast frame rate, such as moving the production of parts off the main thread, at the expense of simplicity in the code. Part of the reason for the slower throughput was obviously due to the unsteady frame rate.

I primarily noticed the degradation on the sending device, but I'd want to profile the receiving device as well, because it has to do a fair amount of computation on each received mixed part.

So feasible, yeah. Fun, no.

[jlopp]

The fact that it works at all is a good start.

As you're performing the data transfer, is there any sort of progress indicator? From my tests the slow loading / signing portions were far less stressful when I had a visual indication that forward progress was being made.

[wolfmcnally]

Yes, I have two progress indicators. One is a typical progress bar, but it shows an estimated percent complete. I picked a fixed value of 1.75 * number of parts, and many times it seems pretty accurate, but it can over or undershoot at times. The other progress indicator is a "fragment bar" that shows a visual map of which parts have and have not been fully received. The disadvantage to that is that it doesn't show the "mixed" fragments that have been received but not yet unmixed. This means that the fragment bar can appear, say, 75% filled but then suddenly you're done, because a necessary part was received that allowed the cascaded unmixing of a bunch of parts. Due to the stochastic nature of the algorithm, I don't think there's a way to give an accurate deterministic progress indicator.

[ChristopherA]

The key thing that our initial airgap QR scenario is from a non-networked device that talks to a networked device. So the 24 minutes is a pain, but at least possible if you have that stringent requirement. For a high-value transaction, say to consolidate a big companies customer inputs every month, that may not be too long given the airgap benefits.

But if both devices have have some form of audio, bluetooth, or network connection, we can do more.

In particular, many low-end devices support an audio in/out jack, so it could be the only wired connection is an audio cable, and you use the QR to bootstrap the two devices to create some type of TOFU Diffie-Helman key agreement between the two devices.

For other pairs of devices that have network, @Fonta1n3 is figuring out how to an ephemeral Tor onion server on the iPhone, and then a QR is only required for the first connection between the trusted signer, where we can potentially do better than TOFU.

-- Christopher Allen