public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <bitcoin-dev@wuille•net>
To: ts <ts@cronosurf•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
Date: Sun, 29 Aug 2021 14:24:48 +0000	[thread overview]
Message-ID: <3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@wuille.net> (raw)
In-Reply-To: <6f69f132-211f-9d42-8023-c3b0264af439@cronosurf.com>

On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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?

I honestly don't understand the point of what you're suggesting.

* If you're concerned about random typos, this is something already automatically protected against through the checksum (both base58check or bech32/bech32m).

* If you're concerned about accidentally entering the wrong - but honestly created - address, comparing any few characters of the address is just as good as any other. It doesn't even require the presence of a checksum. Looking 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 end. 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 designed to look similar in specific places, an attacker can just as easily make the external checksum collide (and having one might even worsen this, as 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 than text (e.g. a visual/drawing/colorcoding one). But I don't see any added value for an additional text-based checksum when addresses are already text themselves. This is even disregarding the difficulty of getting the ecosystem to adopt such changes.

Cheers,

--
Pieter



  reply	other threads:[~2021-08-29 14:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16  4:23 ts
2021-08-16 10:34 ` ZmnSCPxj
2021-08-19 17:02   ` ts
2021-08-19 17:37     ` Christopher Allen
2021-08-21  4:52       ` ts
2021-08-19 21:05     ` Karl
2021-08-21  4:52       ` ts
2021-08-29 14:42     ` Pieter Wuille
2021-08-31  2:17       ` ts
2021-08-28 21:17 ` ts
2021-08-29 14:24   ` Pieter Wuille [this message]
2021-08-31  2:16     ` ts
2021-08-31  8:47       ` Marek Palatinus
2021-09-03  5:08         ` ts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@wuille.net' \
    --to=bitcoin-dev@wuille$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=ts@cronosurf$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox