public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Marek Palatinus <marek@palatinus•cz>
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: Tue, 31 Aug 2021 09:47:26 +0100	[thread overview]
Message-ID: <CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com> (raw)
In-Reply-To: <75a02b16-0aac-4afd-1a9e-f71a8396baea@cronosurf.com>

[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]

I fully agree with sipa and his reasoning that this proposal is not solving
any particular problem, but making it actually a bit worse.

Also, do you know what I hate more than copy&pasting bitcoin addresses?
Copy pasting zillion random fields for SEPA/wire transfers. And I believe
that a single copy pasta of a bitcoin address is a much better user
experience after all.

Best,
slush

On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Pieter, thanks for your comments. Here my thoughts:
>
> Pieter Wuille wrote on 8/29/21 9:24 AM:
> > 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.
>
> It is about creating a simple technical assistance that makes it more user
> friendly and less
> error prone to verify the entered address. For all types of users,
> including those who are
> less tech savvy.
>
>
> > * If you're concerned about random typos, this is something already
> automatically protected against through the checksum (both base58check or
> bech32/bech32m).
>
> I agree, but as mentioned in the original proposal, it is not about random
> typos (although
> this would help for other coins without integrated checksum of course),
> but rather about
> copy&paste errors (both technical or user caused).
>
>
> > * 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.
>
> Correct. However, I believe that ADDITIONALLY to looking at N characters,
> a quick check of a 3
> or 4 digit code in bigger font next to the address would make for a better
> user experience.
> This gives the user the reassurance that there is definitely no error. I
> agree that most users
> with technical background including most of us here will routinely check
> the first/last N
> characters. I usually check the first 3 + last 3 characters. But I don't
> think this is very
> user friendly. More importantly, I once had the case that two addresses
> were very similar at
> precisely those 6 characters, and only a more close and concentrated look
> made me see the
> difference. Moreover, some inexperienced users that are not aware of the
> consequences of
> entering a wrong address (much worse than entering the wrong bank account
> in an online bank
> transfer) might forget to look at the characters altogether.
>
>
> > * 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).
>
> Not so concerned about this case, since this is a very special case that
> can only occur under
> certain circumstances. But taking this case also into consideration, this
> is why the user
> should use the verification code ADDITIONALLY to the normal way of
> verifying, not instead. If
> the attacker only focuses on the verification code, he will only be
> successful with users that
> ONLY look at this code. But if the attacker intends to be more successful,
> he now needs to
> create a valid address that is both similar in specific places AND
> produces the same
> verification code, which is way more difficult to achieve.
>
>
> > 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.
>
> Yes, a visual checksum could also work. Christopher Allen proposed to use
> LifeHash as an
> alternative. It would be a matter of balancing the more complex
> implementation and need of
> space in the app's layout with the usability and advantages of use. One
> advantage of the digit
> verification code is that it can be spoken in a call or written in a
> message.
>
> > This is even disregarding the difficulty of getting the ecosystem to
> adopt such changes.
>
> No changes are needed, only an agreement or recommendation on which
> algorithm for the code
> generation should be used. Once this is done, it is up to the developers
> of wallets and
> exchanges to implement this feature as they see fit.
>
> Greetings,
> TS
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6130 bytes --]

  reply	other threads:[~2021-08-31  8:48 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
2021-08-31  2:16     ` ts
2021-08-31  8:47       ` Marek Palatinus [this message]
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=CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com \
    --to=marek@palatinus$(echo .)cz \
    --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