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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
