From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 38C61C000E for ; 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 ; 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 ; 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 ; 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 ) id 1mKtKn-00AFzC-AM; Mon, 30 Aug 2021 22:17:13 -0400 To: Pieter Wuille , Bitcoin Protocol Discussion References: <8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com> From: ts 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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