"1" and "l" look similar in mono space font when rendering bitcoin addresses

[kirillzh]

The Bitkey app uses mono space font for addresses as recommended by bitcoin.design.

We got some customer feedback that 1 and l look very similar and are hard to distinguish.

Suggestions:

• explore other fonts to reduce the risk of mixing up 1 and ls.

Here's a screenshot from the bitcoin.design demonstrating the issue, it looks practically identical to how we render address in the Bitkey app as well:

[GBKS]

Oh, this is interesting feedback. Here are a few alternatives for comparison.

The bottom three have more unique base shapes for 1 and l, with that curved base on the l. Which font do go with probably depends what fits best with your primary choice of font.

As for the user feedback, were they trying to manually type/copy the address, or compare it to what they saw in another UI to verify accuracy? Or was it another situation?

[yashrajd]

Great feedback...in the Guide screenshot itself the first block on the second line of the address reads '3l06' but most people would probably read it as '3106' (due to the monospace l (L) looks like a 1 in whatever font we used there), especially since it is preceded and followed by a number.

[kirillzh]

As for the user feedback, were they trying to manually type/copy the address, or compare it to what they saw in another UI to verify accuracy? Or was it another situation?

Response from the customer "In that specific case I was trying to manually copy to send from my Lightning Node on Umbrel to Bitkey and there was no ability to scan a QR code.". They mentioned noticing that "1" and "l" very similar while copy-pasting the address.

[GBKS]

Here's what the default Lightning Node UI on Umbrel looks like. For background, Umbrel has both Bitcoin and Lightning nodes as separate applications. The bitcoin one has no send/receive functionality, that is all in the lightning application. This may or may not have been what the customer used, as you can also install other bitcoin/lightning applications on Umbrel.

As @yashrajd mentioned in Discord, the good thing is that lowercase L is not a valid character in bitcoin addresses. That simplifies error detection, you could even limit the input field to not accept those characters at all. Plus, bech32m addresses are designed so that 4 or fewer mistakes can always be detected. So even if the user is not 100% confident about the 1/l situation, the UI can do validation and show a small check to indicate that the address is valid. Particularly for higher amounts, where there's more anxiety, that extra confirmation can help put users at ease.

[kirillzh]

@GBKS makes sense 👍🏻

One of our engineers brought up a pattern that 1Password follows for displaying passwords - they use different colors for numbers and letters, which can help with distinguishing 1s and ls through pattern matching.

[yashrajd]

Also as I mentioned in discord, IIUC the trouble is that the manual check occurs on the sender-side (which may or may not even be our Bitkey user) likely using a different app than Bitkey, we may not have a lot of control in how that app/platform does address formatting or error detection, handling or error messages. Example below 💀:

@GBKS how does the send page and address formatting look in umbrel?

So while I do prima-facie like the idea of different colors for numbers and letters, I wonder how practically useful it is... the real (but perhaps longer-term) solution is moving away from interacting with addresses at all! Silent payments and contacts will be super-useful for that: https://bitcoin.design/guide/how-it-works/silent-payments/#labels--contacts

[GBKS]

Now that we have gathered some different perspectives on this, I'd like to ask the question whether everyone thinks that there is something we should update in the guide. We could, for example:

1. Do nothing
2. Do nothing for now and revisit if other customers also bring this up and/or actual errors occur. This one customer only mentioned noticing the similarity. That does not mean it's necessarily a problem to address, and errors can be caught via validation. See if anecdote turns into data.
3. Add a note in the guide about the character similarities when choosing mono space fonts, and to try to avoid the problem by choosing an appropriate font
4. Suggest the use of color to distinguish letters and numbers
5. ... what else?

Assigning a severity to this issue is probs a good starting point. Personally, I don't see it as severe and think 3 could be a good option, to draw attention to the choice of font, and focusing on this specific character distinction.

What do you think?

[yashrajd]

3 + updated mockup with appropriate monospace font would work for me...

as I said above I suspect there isn't much bitkey or the receiving wallet/app can do in this specific case since manual validation would be done on the send-side. The send/send-review screen should handle this appropriately (as bitkey already does)

[yashrajd]

BTW, I was just able to generate a readable and non-confusing address text using just Inter and the alternative letter options it offers.... what do you all think?

[oli28]

I see the difference between 1 and l clearly. I understand, that some people perceive it differently.
My recommendation is to use font (Inter) or Source Code Pro or Fira Mono.

Small update in the Guide would be super.

• recommended fonts (point 3)
• sometimes color to distinguish letters and numbers would be helpful (point 4)
• UI check/validation to indicate that the address is valid

What do you think? @GBKS and @yashrajd

[GBKS]

Great input, everyone. Should we try to settle this issue?

1. Seems like the original problem was that the applications used did not have QR code display and scanning. That should probably be addressed by those respective apps.
2. UI check/validation should be a no-brainer as well. It is extremely likely that a mistake will result in the address not being valid. The app can also look for this type of mistake specifically. We have a paragraph in the guide right below the one we are discussing here.
3. I like the point about adding a bit of info to the guide about choosing a font whose characters can be clearly distinguished. The paragraph is about visual formatting, so it fits there well.
4. I am not sold about colors to distinguish numbers and letters. It's not a pattern I've seen anywhere else and forcing it on all address displays just for this fringe case seems a big overkill.
5. Another option to clarify things could be to have the UI read the address out aloud - character by character. Browsers, and I believe mobile operating systems as well, have text-to-speech baked in.

I'll create a PR now to address point 3, and we can take it from there. How does that sound?