status of BCR-2020-005 and implementations in the field (cobo and bluewallet)

[m0dB]

Hi,

I recently tried to use the BCR-2020-005 reference code to decode what I supposed were BC-UR format QR codes, only to come to the conclusion that there is a diverging format in the field (so in the end I rolled my own decoder).

Some background: I was trying to use BlueWallet to pass a PSBT to an airgapped Electrum, but Electrum, or rather zbar, which Electrum uses for QR scanning, didn't know what to do with the animated QRs. It could decode the individual QRs and gave me strings in a "UR:BYTES/<sequence>/<data>/<moredata>" format and google took me to the BCR-2020-005 paper.

I decided to add support for these QRs to zbar and started by trying to use the reference code to the decode the strings. Several hours later, after wrestling with the code a lot, I came to the conclusion that despite strong similarities, it wasn't following the same format. I looked at the BlueWallet source code (I later found that they based their implementation on Cobo's) and put together some c++ code and was now able to decode my QRs. Next, I integrated this code in a fork of zbar (adding rudimentary animated QR support). If anyone is interested, the code is here: https://github.com/m0dB/zbar/tree/master/zbar/qrcode/bc-ur . The README explains the format.

While I am happy that I was able to get this to work, the whole experience was a bit worrying. I don't know why there is a format in the field that is diverging from the paper (maybe it was based on an earlier proposal?) but I don't think it's necessarily an issue as I am sure both formats can exist next to each other (and apparently the Cobo/BlueWallet format has gained some traction). But it definitely is something to keep in mind as it can be quite confusing. And if both formats have to coexists, it will be important for decoders to be aware of this.

[m0dB]

Heh, I see I should have read this discussion first: #26

It would have helped me a lot if the paper had mentioned and briefly described the existence of this earlier format and it certainly would be nice if the reference code could support or at least detect and inform about the format (though I see how that doesn't belong in a reference implementation).

[AndreasGassmann]

I think the issue is that the version of the standard that Cobo and BlueWallet are using (sometimes called bc-ur v1), was not actually finalised and never intended to be implemented like that, but rater it was in a "RFC" state. (At least that's how I understood it by reading all the related issues).

For AirGap Vault, we are planning to add the current bc-ur (v2) standard. I hope BlueWallet will be compatible by then, because I would prefer not to add any "legacy" code that was never really a standard. The BlueWallet devs said that they will basically do whatever Cobo does, and Cobo said they plan to work in bc-ur v2 in April. So if all goes well, the "old" standard might be gone already in 2 months.

I'm not sure if Electrum was ever part of the discussions around bc-ur and if they intend to support it. But I really hope they do, because it seems to be adopted as a standard and then Electrum support would be an important part.