From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CEA2EC000E for ; Sun, 29 Aug 2021 14:32:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B7F1B40193 for ; Sun, 29 Aug 2021 14:32:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 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, 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 xl-XDVCKapZn for ; Sun, 29 Aug 2021 14:32:27 +0000 (UTC) X-Greylist: delayed 00:07:33 by SQLgrey-1.8.0 Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27]) by smtp2.osuosl.org (Postfix) with ESMTPS id 81A054011F for ; Sun, 29 Aug 2021 14:32:27 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) (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-4321.protonmail.ch (Postfix) with ESMTPS id 4GyG2M09vzz4xCDs for ; Sun, 29 Aug 2021 14:25:30 +0000 (UTC) Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=wuille.net header.i=@wuille.net header.b="hCFYnijl" Date: Sun, 29 Aug 2021 14:24:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail; t=1630247090; bh=QTjnyBzpO5AkMFbwtDsYL9/AsdU1nUoXpVTtff7ZXkc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=hCFYnijlT44fXnhRjATuaqsW7Ju+x53obW5dYdGXyfdID+l3n6Kn9r5/1C9Ep+zSr 4fYXjn+6YpxOYyKtG0UQPpyKjrsjwEWlTTbxez6QgUhzpf4tDRcNj+ZpYNX4djPsS0 yam8VBDS1bMTHpTXw4g6grBdYyKOQphWimdejgRFUDNOKvm89Gevzbg6dT+N3OKtam PjPolK5ucobJR2yPX+JypjHjVhtq+vK0AYA1Jmq+ql41VhSF+h0mGDcwzY1Zb3klPT VAydNOcqVzvOv8XZIXhfb3IUoDOJjC/bw6iZz1tBB+x3+lyDpPvFYfDPRJQXHruHrl bORXzZFFpUmAw== To: ts , Bitcoin Protocol Discussion From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: <3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@wuille.net> In-Reply-To: <6f69f132-211f-9d42-8023-c3b0264af439@cronosurf.com> References: <6f69f132-211f-9d42-8023-c3b0264af439@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:32:32 -0000 On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev wrote: > Following up on my original proposal, I would like to get some more feedb= ack 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? I honestly don't understand the point of what you're suggesting. * If you're concerned about random typos, this is something already automat= ically protected against through the checksum (both base58check or bech32/b= ech32m). * If you're concerned about accidentally entering the wrong - but honestly = created - address, comparing any few characters of the address is just as g= ood as any other. It doesn't even require the presence of a checksum. Looki= ng at the last N characters, or the middle N, or anything except the first = few, will do, and is just as good as an "external" checksum added at the en= d. For randomly-generated addresses (as honest ones are), each of those has= exactly as much entropy. * If you're concerned about maliciously constructed addresses, which are de= signed to look similar in specific places, an attacker can just as easily m= ake the external checksum collide (and having one might even worsen this, a= s now the attacker can focus on exactly that, rather than needing to focus = on every other character). Things would be different if you'd suggest a checksum in another medium tha= n text (e.g. a visual/drawing/colorcoding one). But I don't see any added v= alue for an additional text-based checksum when addresses are already text = themselves. This is even disregarding the difficulty of getting the ecosyst= em to adopt such changes. Cheers, -- Pieter