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
|
Return-Path: <ts@cronosurf.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 946B4C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Aug 2021 17:02:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 75108613B9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Aug 2021 17:02:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.015
X-Spam-Level:
X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.117, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham 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 nE2EAl3wp4bK
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Aug 2021 17:02:45 +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 3C5DC605FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 19 Aug 2021 17:02:45 +0000 (UTC)
Received: from [189.172.54.124] (port=44724 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 1mGlR9-001skL-OV; Thu, 19 Aug 2021 13:02:44 -0400
From: ts <ts@cronosurf.com>
To: bitcoin-dev@lists.linuxfoundation.org
References: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
<aO1qYUmtGXPJupl0ol3E221AR4XKwqriqk3Y5fVS2_asquaV8Vaxkb4Ffq2EiVMrR5bb4cXAzxAV3cOciaYsuqJoFXoc6vTOoveKURVTmLU=@protonmail.com>
Message-ID: <8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com>
Date: Thu, 19 Aug 2021 12:02:38 -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: <aO1qYUmtGXPJupl0ol3E221AR4XKwqriqk3Y5fVS2_asquaV8Vaxkb4Ffq2EiVMrR5bb4cXAzxAV3cOciaYsuqJoFXoc6vTOoveKURVTmLU=@protonmail.com>
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: Thu, 19 Aug 2021 17:14:30 +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: Thu, 19 Aug 2021 17:02:46 -0000
Hello ZmnSCPxj,
ZmnSCPxj wrote on 8/16/21 5:34 AM:
> Good morning TS,
>
>> Entering a BTC address for a transaction can pose a risk of error (human or technical). While
>> there is a checksum integrated in BTC addresses already, this is used only at a technical
>> level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not
>> improve the overall user experience.
>>
>> In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets
>> call it 4DC for this text), generated as checksum from the address. This 4DC should be shown
>> in all wallets next to the receiving address. When entering a new address to send BTC, the
>> sending wallet should also show the 4DC next to the entered address. This way, the sending
>> person can easily verify that the resulting 4DC matches the one from the receiving address.
>>
>> This would mean that a receiver would not only send his public address to the sender, but also
>> the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very easy to do.
>> However, it would greatly reduce the probability of performing transactions to a wrong address.
>>
>> Technically, this is very easy to implement. The only effort needed is agreeing on a checksum
>> standard to generate the code. Once the standard is established, all wallet and exchange
>> developers can start implementing this.
>
Thanks for your comments.
> I think the "only" effort here is going to be the main bulk of the effort, and it will still take years of agreement (or sipa doing it, because every review is "either sipa made it, or we have to check *everything* in detail for several months to make sure it is correct").
I understand. If sipa could do it that would greatly simplify the process. Once an algorithm
for the generation of the code exists, it just needs to be communicated to wallet developers
and let it grow organically. No need of extensive testing, since it is only a very simple
function.
> 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?
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
fixed by the wallet by showing those digits bigger or separately)
d) and most importantly: as mentioned in above my proposal, it only proves that an address is
valid, but not necessarily the correct one (perhaps the user copied the wrong address, there
was an old address in the clipboard, etc.)
> On the other side of the coin, if you say "the existing bech32 checksum is automatically checked by the software", why is forcing something to be manually checked by a human better than leaving the checking to software?
Not better, it should be on top. And not forced, but just as an optional check for the user.
The SW can (and should) only check that the address is valid (the SW doesn't know the user's
intent). Only the human can "double-check" an easy-to-read-code to quickly know that he is
doing the right thing. (Entering a valid but wrong address is even worse than entering an
invalid one, since the latter will be stopped by the wallet. But the former most likely
results in loosing the funds.)
Note: The code should never be entered manually or even copied together with the address in
one string. From the SW point of view, the code is an output only, never an input. It is
merely a visual verification for the user.
Example of use: person A calls via phone person B and says: "Send me 0.1 BTC to my address I
just sent you via whatsapp. When entering the address, make sure that you get the verification
code 4385."
Regards,
TS
>
>
> Regards,
> ZmnSCPxj
>
|
