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
|
Return-Path: <ts@cronosurf.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id C1675C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:16:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id A4A42404FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:16:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.802
X-Spam-Level:
X-Spam-Status: No, score=0.802 tagged_above=-999 required=5
tests=[BAYES_50=0.8, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id MCsbJxcisEbH
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:16:07 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 83FD04040D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Aug 2021 02:16:07 +0000 (UTC)
Received: from [189.174.9.220] (port=34288 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 1mKtJh-00AEWG-OW; Mon, 30 Aug 2021 22:16:06 -0400
To: Pieter Wuille <bitcoin-dev@wuille.net>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
<6f69f132-211f-9d42-8023-c3b0264af439@cronosurf.com>
<3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@wuille.net>
From: ts <ts@cronosurf.com>
Message-ID: <75a02b16-0aac-4afd-1a9e-f71a8396baea@cronosurf.com>
Date: Mon, 30 Aug 2021 21:16:00 -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: <3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@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=-1.0
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:16:08 -0000
Pieter, thanks for your comments. Here my thoughts:
Pieter Wuille wrote on 8/29/21 9:24 AM:
> On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Following up on my original proposal, I would like to get some more feedback of the community
>>
>> to see if this could be realized at some point. Also, any recommendations as to who to contact
>>
>> to get things rolling?
>
> I honestly don't understand the point of what you're suggesting.
It is about creating a simple technical assistance that makes it more user friendly and less
error prone to verify the entered address. For all types of users, including those who are
less tech savvy.
> * If you're concerned about random typos, this is something already automatically protected against through the checksum (both base58check or bech32/bech32m).
I agree, but as mentioned in the original proposal, it is not about random typos (although
this would help for other coins without integrated checksum of course), but rather about
copy&paste errors (both technical or user caused).
> * If you're concerned about accidentally entering the wrong - but honestly created - address, comparing any few characters of the address is just as good as any other. It doesn't even require the presence of a checksum. Looking at the last N characters, or the middle N, or anything except the first few, will do, and is just as good as an "external" checksum added at the end. For randomly-generated addresses (as honest ones are), each of those has exactly as much entropy.
Correct. However, I believe that ADDITIONALLY to looking at N characters, a quick check of a 3
or 4 digit code in bigger font next to the address would make for a better user experience.
This gives the user the reassurance that there is definitely no error. I agree that most users
with technical background including most of us here will routinely check the first/last N
characters. I usually check the first 3 + last 3 characters. But I don't think this is very
user friendly. More importantly, I once had the case that two addresses were very similar at
precisely those 6 characters, and only a more close and concentrated look made me see the
difference. Moreover, some inexperienced users that are not aware of the consequences of
entering a wrong address (much worse than entering the wrong bank account in an online bank
transfer) might forget to look at the characters altogether.
> * If you're concerned about maliciously constructed addresses, which are designed to look similar in specific places, an attacker can just as easily make the external checksum collide (and having one might even worsen this, as now the attacker can focus on exactly that, rather than needing to focus on every other character).
Not so concerned about this case, since this is a very special case that can only occur under
certain circumstances. But taking this case also into consideration, this is why the user
should use the verification code ADDITIONALLY to the normal way of verifying, not instead. If
the attacker only focuses on the verification code, he will only be successful with users that
ONLY look at this code. But if the attacker intends to be more successful, he now needs to
create a valid address that is both similar in specific places AND produces the same
verification code, which is way more difficult to achieve.
> Things would be different if you'd suggest a checksum in another medium than text (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an additional text-based checksum when addresses are already text themselves.
Yes, a visual checksum could also work. Christopher Allen proposed to use LifeHash as an
alternative. It would be a matter of balancing the more complex implementation and need of
space in the app's layout with the usability and advantages of use. One advantage of the digit
verification code is that it can be spoken in a call or written in a message.
> This is even disregarding the difficulty of getting the ecosystem to adopt such changes.
No changes are needed, only an agreement or recommendation on which algorithm for the code
generation should be used. Once this is done, it is up to the developers of wallets and
exchanges to implement this feature as they see fit.
Greetings,
TS
|
