Date: Mon, 16 Aug 2021 10:34:36 +0000
To: ts <ts@cronosurf.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <aO1qYUmtGXPJupl0ol3E221AR4XKwqriqk3Y5fVS2_asquaV8Vaxkb4Ffq2EiVMrR5bb4cXAzxAV3cOciaYsuqJoFXoc6vTOoveKURVTmLU=@protonmail.com>
In-Reply-To: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
References: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Human readable checksum (verification code) to
	avoid errors on BTC public addresses
Precedence: list

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 onl=
y at a technical
> level and does not avoid entering a valid but otherwise wrong address. Mo=
reover, 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 v=
ery easy to do.
> However, it would greatly reduce the probability of performing transactio=
ns to a wrong address.
>
> Technically, this is very easy to implement. The only effort needed is ag=
reeing on a checksum
> standard to generate the code. Once the standard is established, all wall=
et and exchange
> developers can start implementing this.

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").

In any case --- the last 5 characters of a bech32 string are already a huma=
n-readable 5-digit code, with fairly good properties, why is it not usable =
for this case?

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 manu=
ally checked by a human better than leaving the checking to software?


Regards,
ZmnSCPxj