1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <ts@cronosurf.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 38C61C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:17:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 1BDE360B94
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:17:15 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.281
X-Spam-Level:
X-Spam-Status: No, score=0.281 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=1.798, NICE_REPLY_A=-0.117,
PDS_BTC_ID=0.498, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=no autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Zg3Ru0piVXpv
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:17:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from premium29-m.web-hosting.com (premium29-m.web-hosting.com
[68.65.120.189])
by smtp3.osuosl.org (Postfix) with ESMTPS id 7A96E60B53
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:17:14 +0000 (UTC)
Received: from [189.174.9.220] (port=34306 helo=[192.168.1.88])
by premium29.web-hosting.com with esmtpsa (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2)
(envelope-from <ts@cronosurf.com>)
id 1mKtKn-00AFzC-AM; Mon, 30 Aug 2021 22:17:13 -0400
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
<aO1qYUmtGXPJupl0ol3E221AR4XKwqriqk3Y5fVS2_asquaV8Vaxkb4Ffq2EiVMrR5bb4cXAzxAV3cOciaYsuqJoFXoc6vTOoveKURVTmLU=@protonmail.com>
<8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com>
<ZJqjnpWzG9qKb0N02X9WLkBM2hRWk7w0hmAXlIuHj1bQZptdxVJzdVGXAwSPjkM187aRo5GkQq4oSnCurryxKRkWTeA5HgNL9VxmFMoTpF4=@wuille.net>
From: ts <ts@cronosurf.com>
Message-ID: <58562a1c-b1e3-95da-59b6-6cd5eae0b137@cronosurf.com>
Date: Mon, 30 Aug 2021 21:17:07 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <ZJqjnpWzG9qKb0N02X9WLkBM2hRWk7w0hmAXlIuHj1bQZptdxVJzdVGXAwSPjkM187aRo5GkQq4oSnCurryxKRkWTeA5HgNL9VxmFMoTpF4=@wuille.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-0.8
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - premium29.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - cronosurf.com
X-Get-Message-Sender-Via: premium29.web-hosting.com: authenticated_id:
ts@cronosurf.com
X-Authenticated-Sender: premium29.web-hosting.com: ts@cronosurf.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Mailman-Approved-At: Tue, 31 Aug 2021 08:07:56 +0000
Subject: Re: [bitcoin-dev] Human readable checksum (verification code) to
avoid errors on BTC public addresses
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2021 02:17:15 -0000
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
|
