[solved] QtQr adds invisible characters front of the string in the QRcode

[openoms]

Shared the robot code to mobile and different avatar came up without the ongoing trade.

Tor Browser on Android: 99.0.0b3 (11.5)

Latest Tor Browser on desktop + Brave was consistent with the original account.

Previously could recover the same account on mobile.

[Reckless-Satoshi]

Shared the robot code to mobile and different avatar came up without the ongoing trade.

Do you know what are the steps I should take to replicate this bug? In order to better identify this bug and fix it, it would be great if we can find a token (not the one you are using) for which this behavior is true (i.e., generates a different robot in desktop and mobile).

I assume you did good diligence before reporting, but are you sure the token did not corrupt while transferring devices? When manually entering a token, it is important to note that base64 has both I and l and 0 and O. These might look identical with some fonts. I have recovered a robot from device to device many times. Sometimes, I recovered a different robot, but always found out it was my mistake when typing.

The frontend token hashing function is the same for both desktop and mobile (in fact, the whole frontend is the same). The hash of the token is the robot identity, so same hash -> same avatar. It would be surprising, at this stage, if this setup is not reliable.

[openoms]

steps taken:

• start trade on desktop, save token as offered (copy-paste)
• share token via Linux QtQR and Binary Eye on Android - confirmed the same visually.
• on Android the avatar and name is different - reproducible with this code.
• the original account is recoverable on desktop.
  Due to the nature of the trade will be able to share the robot token privately after finished.

[Reckless-Satoshi]

I was able to replicate your issue, I am puzzled. These are my findings: Linux QtQR generates a QR whose token is different.

Using the following QR encoding software solved the issue for me:

apt install qrencode
qrencode -o token.png <TOKEN>

QR code generated by QtQR:

QR code generated by qrencode:

These two token strings seem identical. Yet, they are different. The frontend recognizes they are different when you replace one by the other (the "generate Robot" button turns blue, that does not happen if you replace text by itself by copy/pasting).

Using qrcode-decoder.com to decode the QtQR token, it seems to add characters  at the beginning of the sequence. These do not render into anything in Binary Eye, nor SecScanQR in Android (nor the RoboSats text input): but these characters are still there and the SHA256 comes out different.

[Reckless-Satoshi]

Assuming the issue is exclusive to QtQR, maybe the best solution is to simply avoid this tool and document it. This problem might also occur and be very annoying if you use it to copy a password or a BTC address to your device.

I tested whether this hypothesis is true by sending a txid from mempool.space to the Android device:

1. Find a txid hex in mempool.space
2. Generate a QR code with QtQR and scan with SecScanQR on Android
3. Navigate to mempool.space/tx/<past_txid> in the Android device

The result is "Invalid hex string" .

One can also see on the browser bar that the URL has characters %EF%BB%BF ( the Byte order mark for UTF-8 also ). I wonder whether it is typical practice to include this mark on QR codes or copy these bytes into the clipboard 🤔

As a solution for future users encountering a similar problem, the frontend could check for %EF%BB%BF at the start of the token sequence. Yet, one would think browsers are already this smart.

[openoms]

This is scary as I was using QtQr occasionally for various things including sharing invoices and PSBTs. Well won't do it any more. Likely other projects would benefit from a warning as well.

Regarding the example QRs above Binary Eye does display the problem in the hex representation and showing empty characters at the beginning of the token:

vs the second picture:

[openoms]

Clearly not a problem with Robosats, renaming and happy to close.

[jpph]

Fwiw, EFBBBF is UTF-8 BOM (byte order mask), when handling such string, your code should remove it