Replace quirc and BC-UR libraries with lighter pure-C implementations

[odudex]

This PR proposes, for your evaluation, replacing two libraries in the QR scan/display path:

• components/esp32-quirc → k_quirc submodule — QR decoding
• components/esp32_bc-ur (C++) → cUR (C) submodule — BC-UR transport (bytewords, fountain codes, multi-part assembly)

Both were originally developed for Kern and Krux projects. cUR is used envelope-only: all payload CBOR stays in TinyCBOR in main/bcur.c, and main/bcur.h is unchanged, so no callers needed modification. A third small commit makes the libjade ESP_LOG mocks accept non-literal tags (k_quirc logs with a TAG variable).

Measured impact (esp32s3 dev config, vs master)

	master	this PR	Δ
jade.bin	1,554,976 B	1,520,160 B	−34.8 KB (−2.2%)
QR decoder flash	30.6 KB	15.2 KB	−50%
UR library flash	23.7 KB	12.1 KB	−49%
libstdc++	4.7 KB	1.5 KB	−3.2 KB

• QR decoding is ~2.5× faster on the repo's 13 qr_qvga_* camera fixtures (desktop benchmark feeding the same 220×220 scan input to both decoders at -O2; per-image speedups 1.9–3.2×, decode parity 13/13).
• QEMU on-device selfcheck: 166.6 s → 144.9 s (−13%). The selfcheck includes non-UR tests common to both builds, so the UR-specific gain is larger than the headline number.

Compatibility and verification

• The selfcheck bcur tests pass with the original vectors, including the byte-exact comparison of encoded UR:CRYPTO-PSBT parts, wire-format parity with bc-ur. Fountain fragments are additionally cross-validated in cUR's own test suite against foundation-ur-py output.
• One selfcheck expectation adjusted: cUR dedupes a repeated fragment before counting it, so processed_parts stays at 1 when the same part is presented twice (bc-ur counted 2).
• Full test_jade.py passes via libjade, including the multi-part UR:CRYPTO-PSBT camera-scan fixture.
• On-device selfcheck passes under QEMU for both qemu configs (default, and --psram --unamalgamated).
• Builds verified: esp32 and esp32s3 dev configs, qemu, and the libjade host build.

Caveats

• Both libraries are young compared to quirc/bc-ur. k_quirc carries a CI-enforced synthetic validation matrix (8k+ decode cases) and a desktop test harness; cUR has a unit-test suite run under ASan/UBSan and validated against foundation-ur-py vectors. Review is very welcome, and I'm happy to address findings in the upstream repos.
• cUR adds decode-side hardening caps absent from bc-ur (1024 fragments / 256 KiB message, both compile-time overridable).

Motivation

If all goes well, give back from DIY community to the Jade project and at the same time get reviews to help harden these tools.

[jgriffiths]

Hi @odudex awesome stuff!

I have been irked by bc-ur for a long time (we also use it in gdk) - .the c++ impl is inefficient and unwieldy to work with, and the upstream maintainers are resistant to any kind of changes. Its long been a dream of mine to have time to rewrite it as clean C, so its great to see you've done exactly that :)

The code size reduction and performance improvements are also very welcome, so I'm very interested in merging these changes. Swapping from our current impl would require us to fully review/test both libraries, which will take a while, and we'd almost certainly do this a library at a time, starting with bc-ur.

So please bear with us as we review cUR first and then we will look at migrating to it in due course.

[jgriffiths]

Note I've cherry-picked the libjade change into master so you don't have to keep carrying it.

[odudex]

Great to hear there's a demand for cUR! Your review and feedback are really welcome, and you can count on me to make adjustments if needed.

[jgriffiths]

I'd say for the purposes of keeping this more easily rebase-able, it would be a good idea to structure it as the following:

• Add cUR component, no other changes
• Update source to use cUR
• Add k_quirc component, no other changes
• Update source to use k_quirc

I'd leave the removal of the existing components out for now since nuking them after the migration is trivial, and rebasing with them deleted will be painful if there are changes there while this is under review.

[odudex]

Commits structured as requested.

[odudex]

Done:

cUR:

• Refactored the decoder API: the is_complete/is_success/get_last_error trio is replaced by a single state machine - receive_part() now returns the resulting state directly. Terminal states are permanent; all other errors are transient, so scan loops can keep feeding parts past misread QR frames.
• Replaced double with float where possible (progress estimates are display-only and embedded FPUs are single-precision). Fragment-selection math intentionally stays double: the UR standard requires bit-identical part-index derivation across implementations.
• Encoder now builds its fountain degree sampler once per message instead of on every part, cutting soft-float ops and allocations from next_part().

Jade:

• Adapted bcur.c and selfcheck.c to the new API. The state machine collapsed the old success/complete/failure check combinations into single exact-state assertions.
• Added a second UR commit: the animated-QR progress bar now uses the lib's weighted completion estimate, which also credits not-yet-resolved mixed fountain parts. It has a more linear progress UX.

[jgriffiths]

The state machine collapsed the old success/complete/failure check combinations into single exact-state assertions.

Perfect, this is exactly what I envisioned with the state based API :)

[odudex]

cUR had a fix and improvements on recent push.

[jgriffiths]

@odudex I'm dubious about the cUR optimizations added TBH. e.g.:

• defaulting to adding an 8kb table to make crc calculation slightly faster is nuts for embedded targets (the most likely projects to need a lib like cUR vs the reference impl).
• In the xor change to use uint64_t - esp32 has no 64 bit registers, so working on integer sizes larger 32bit is always going to be slower since 64 bit is emulated with 2 32-bit registers. Given the following simd changes increase the memory alignment this should probably just be a loop over uint32_t pointers without the memcpy-to-register nonsense (this could use a 64 bit loop for 64 bit cpus).

IMO cUR is too young a project to be complicating the impl with micro-optimizations when you are still making high level changes like design optimizations and API cleanups, and still finding bugs. At the very least these changes should be (1) separate re-implementations of functions, not ifdef'd code complicating the existing functions (2) default to a reasonable size/speed tradeoff and (3) be gated by cpu defines only (so builders don't have to iterate the source files trying to determine which set of platform defines they need to set). I also think you might want to hold micro-optimizations back until the library has been completely tested/reviewed, although that last one is just IMO.

Finally, please note that the github user greenaddress is no longer associated with Blockstream or Blockstream Green in any way.

[odudex]

@odudex I'm dubious about the cUR optimizations added TBH

Fair points, most of them taken.

• CRC32 now defaults to the 64-byte nibble table everywhere. Slice-by-8 is opt-in (still built in CI).
• The XOR is split into two complete implementations, portable and P4 vector, behind a single top-level ifdef like crc32.c. No more ifdefs inside function bodies.
• The portable loop chunks by pointer width (uint32_t on 32-bit). The memcpy stays: a raw uint32_t * cast is UB under strict aliasing, and at -O2 the codegen is identical (checked the rv32 disassembly).
• The P4 path is gated by IDF_TARGET_ESP32P4 with a menuconfig opt-out. The README now has one table with every option, its default, and its cost.
• Agreed on timing: micro-optimizations are frozen. I'll prioritize fixes and hardening.

For Jade, UR_ENVELOPE_ONLY=ON with default options builds just the transport layer, close to reference complexity.

[odudex]

cUR + k_quirc on the right:

Jade_r.mp4