From: ts <ts@cronosurf•com>
To: Pieter Wuille <bitcoin-dev@wuille•net>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
Date: Mon, 30 Aug 2021 21:17:07 -0500 [thread overview]
Message-ID: <58562a1c-b1e3-95da-59b6-6cd5eae0b137@cronosurf.com> (raw)
In-Reply-To: <ZJqjnpWzG9qKb0N02X9WLkBM2hRWk7w0hmAXlIuHj1bQZptdxVJzdVGXAwSPjkM187aRo5GkQq4oSnCurryxKRkWTeA5HgNL9VxmFMoTpF4=@wuille.net>
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
next prev parent reply other threads:[~2021-08-31 2:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 4:23 ts
2021-08-16 10:34 ` ZmnSCPxj
2021-08-19 17:02 ` ts
2021-08-19 17:37 ` Christopher Allen
2021-08-21 4:52 ` ts
2021-08-19 21:05 ` Karl
2021-08-21 4:52 ` ts
2021-08-29 14:42 ` Pieter Wuille
2021-08-31 2:17 ` ts [this message]
2021-08-28 21:17 ` ts
2021-08-29 14:24 ` Pieter Wuille
2021-08-31 2:16 ` ts
2021-08-31 8:47 ` Marek Palatinus
2021-09-03 5:08 ` ts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58562a1c-b1e3-95da-59b6-6cd5eae0b137@cronosurf.com \
--to=ts@cronosurf$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bitcoin-dev@wuille$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox