Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

[ts <ts@cronosurf.com>]

Pieter Wuille wrote on 8/29/21 9:42 AM:
> On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>>> In any case --- the last 5 characters of a bech32 string are already a human-readable 5-digit code, with fairly good properties, why is it not usable for this case?
> 
> Side note: it's actually the last six characters.
> 
>>
>> Well, because
>>
>> a) most people don't know that
>>
>> b) it is specific to bech32
>>
>> c) it is not easily readable being the last digits of a long address (although this could be
> 
> I think this is a misconception. For the purpose of verifying that you have the *right* address (rather than just a valid one), the checksum, or even the knowledge that a checksum is present, is completely irrelevant.

Exactly, it is irrelevant in that case. That's why I added d) "...it only proves that an 
address is valid, but not necessarily the correct one..."


> In honestly-generated addresses, every character except the prefix (the ~2 first characters for P2PKH and P2SH, and the ~4 first characters for BIP173/BIP350 native segwit addresses) has exactly the same amount of entropy. Instead of adding say a 4 character code, just tell people to compare any 4 characters of their choosing. Or more - I would hope people are already comparing (much) more than 4 characters already.
> 
> It doesn't matter if the characters being compared are checksum characters or data characters. In honestly-generated addresses, both are equally random.

Yes, I agree with this basically, the entropy would be the same. My proposal is all about 
improving the user experience.


> Adding a special 4 character "external" checksum IMO would instead encourage people to perhaps just compare those 4 characters instead of the rest (or at least, focus mostly on those). That could easily worsen how well comparisons are done in practice...

This is a good point. This feature should not encourage people to just compare the code on its 
own or to focus mostly on it. It should be understood as a verification ON TOP. But then 
again, is there a perfect solution? As it is now, most users focus on only a few characters, 
if any.

* New variant
This discussion is now leading me to a new thought. Since the entropy is the same with a given 
number of characters from the address as you say and the address has already an inbuilt 
checksum, an alternative way to do this would be to just take 4 or 5 characters (as you 
proposed above) from a fixed position and present them to the user separately. Say, characters 
from position 11th to 15th. Those 5 characters should be displayed by the wallet next or 
bellow to the address in a clear box and big font. It could be called "Quick Verification Box" 
or some other catchy name.

Of course, the user could do this by looking at the address on his own. But this way he is 
encouraged to look at a given number of characters. Plus, a the bigger font makes it easier to 
see.

Example (characters 11th-15th):
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [YC8eo] <- in a bigger font
            ^^^^^

Or alternatively, the first 2 characters, chars. at position 11 and 12, and the last 2 characters:
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [1K-YC-vg] <- in a bigger font
^^         ^^                   ^^

Or characters at pos. 11-13 and 18-20:
1KM7GsxUvQiYC8eohKA2QHr9fCjkJXDFvg  [YC8-A2Q] <- in a bigger font
            ^^^    ^^^

Whatever combination is used, the important thing is that it becomes a standard and all 
wallets use the same one.

The advantage of this solution is that it would be technically even easier to implement, and 
more transparent at the same time. It is again all about agreeing on which characters to pick.


* Avoiding the confusion among networks (or blockchains)
In my original proposal, I mentioned that each network should use its own code generation 
algorithm. This way, for networks sharing the same address format, like BTC and BCH, the user 
would have this extra level of verification (in case he intends to send coins from BCH network 
to BTC or viceversa).
For the new variant above, this is easy to achieve too - each network should agree on a 
different subset of characters,

I hope I could explain this clearly enough, and that someone can see a value in this.

Cheers,
TS