Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 56264C000E for ; Sat, 28 Aug 2021 21:17:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 48E4E60651 for ; Sat, 28 Aug 2021 21:17:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.117, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 V3Brp7Egdm7G for ; Sat, 28 Aug 2021 21:17:42 +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 838C96063D for ; Sat, 28 Aug 2021 21:17:42 +0000 (UTC) Received: from [189.174.9.220] (port=40044 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 1mK5hp-00EEAj-6K for bitcoin-dev@lists.linuxfoundation.org; Sat, 28 Aug 2021 17:17:41 -0400 From: ts To: bitcoin-dev@lists.linuxfoundation.org References: Message-ID: <6f69f132-211f-9d42-8023-c3b0264af439@cronosurf.com> Date: Sat, 28 Aug 2021 16:17:35 -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, 28 Aug 2021 22:30:07 +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, 28 Aug 2021 21:17:43 -0000 Following up on my original proposal, I would like to get some more feedback of the community to see if this could be realized at some point. Also, any recommendations as to who to contact to get things rolling? Thanks, TS ts wrote on 8/15/21 11:23 PM: > 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 only at a technical > level and does not avoid entering a valid but otherwise wrong address. Moreover, 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 (or communicate it via a different channel). A minor disadvantage since a) it is not > mandatory and b) it is very easy to do. > However, it would greatly reduce the probability of performing transactions to a wrong address. > > Technically, this is very easy to implement. The only effort needed is agreeing on a checksum > standard to generate the code. Once the standard is established, all wallet and exchange > developers can start implementing this. > > Agreeing on a good name for this code would be helpful for a fast adoption (human readable > checksum, verification code or 4DC are just examples). > > Obviously, this solution could be used for all other coins/networks. But ideally, each of them > should have its own checksum algorithm, in order to further avoid sending funds to the wrong > network. Especially when the address standard is the same like it is the case with BTC and BCH. > > Hopefully, Bitcoin can implement this first and serve as example-to-follow to other > coins/networks. > > Cheers, > TS