Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B931DC000E for ; Sun, 29 Aug 2021 14:42:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A4E25400FD for ; Sun, 29 Aug 2021 14:42:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=wuille.net Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIh4dZJ98EgL for ; Sun, 29 Aug 2021 14:42:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch [185.70.41.103]) by smtp2.osuosl.org (Postfix) with ESMTPS id C64ED4011F for ; Sun, 29 Aug 2021 14:42:21 +0000 (UTC) Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com [188.165.51.139]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by mail-41103.protonmail.ch (Postfix) with ESMTPS id 4GyGPl3qNhz4x4Ck for ; Sun, 29 Aug 2021 14:42:19 +0000 (UTC) Authentication-Results: mail-41103.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="A+ehTiIp" Date: Sun, 29 Aug 2021 14:42:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail; t=1630248129; bh=/pSk/6Gq/gPMQgUZeA/+xK6cLmuyq+VSmfxnc8d+/4k=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=A+ehTiIpW5OaoYc9QA2sSRDEdaXU6sPtUw7Bjyfs+xBpFz+fuP1vYMDMiY6hk4Smm H6W2dkJ//ldVGjcFNswxpRgkvM0Z8w1Wf4RRVXtj/VcSe2Frp9dWQkPaC3ujU49idy ay3vBBA4dR1tS636Ih1fKGLrwq+cZeIX8ByVhqEJJVzNxX22zv5r+zFeWPBJsIhi6N 8555BhIToVmEvLVSI5C2gZ+/ft9tNCvugWZsqEQ4mmt160zBHbVnZ3TXX4emh9GI8y RdupQG6tgOob8S4LaUjQWZsG7bK6ALjNZAlaTzoT8NUHYlQjnruUmul92hEu/vfIWa UdCmu9g0l9StA== To: ts , Bitcoin Protocol Discussion From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: <8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com> References: <8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 29 Aug 2021 16:26:37 +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: Sun, 29 Aug 2021 14:42:26 -0000 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 usa= ble 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 (alt= hough 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. 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. In= stead of adding say a 4 character code, just tell people to compare any 4 c= haracters of their choosing. Or more - I would hope people are already comp= aring (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 rando= m. Adding a special 4 character "external" checksum IMO would instead encourag= e 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 compar= isons are done in practice... Cheers, -- Pieter