+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

+

+