From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 60F60C000E for ; Sat, 21 Aug 2021 04:52:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 425B4400D0 for ; Sat, 21 Aug 2021 04:52:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 qQJig2W7nIlZ for ; Sat, 21 Aug 2021 04:52:34 +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 smtp2.osuosl.org (Postfix) with ESMTPS id 3CB214013B for ; Sat, 21 Aug 2021 04:52:34 +0000 (UTC) Received: from [189.174.9.220] (port=55342 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 1mHIzb-000kxL-L9; Sat, 21 Aug 2021 00:52:33 -0400 To: Karl , Bitcoin Protocol Discussion References: <8565f40b-2f32-cf31-6c47-971a6e57cb41@cronosurf.com> From: ts Message-ID: Date: Fri, 20 Aug 2021 23:52:26 -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=-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: Sat, 21 Aug 2021 07:50:26 +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: Sat, 21 Aug 2021 04:52:38 -0000 Hello Karl, Yes, I agree in general. But while the visual checksum could be sometimes more interesting and even useful, I guess that the technically simpler solution might be more likely to be adopted. And also less prone to error. Just a thought. Cheers, TS Karl wrote on 8/19/21 4:05 PM: > Something that could work really well here could be having a norm of using the checksum for > bright colors, weights, sizes, capitalizations, and/or spacing of the characters of the > address, making different addresses more clearly visually distinct. > > Ethereum uses mixed case to do this a little bit: > https://eips.ethereum.org/EIPS/eip-55#implementation > > > It seems to me the checksum at the end of the address is sufficient for differentiating error, > but making a checksum more visually distinctive is indeed an opportunity to add another > digest, reducing collisions and such.