MIME-Version: 1.0
References: <f31bc6b0-f9b3-be4c-190c-fc292821b24b@cronosurf.com>
 <6f69f132-211f-9d42-8023-c3b0264af439@cronosurf.com>
 <3isqiyeCtgJdzEvbbm3ZoS6h1_4l3YjtPypqJAPto5cp2K1BebmgEdVGLGTYt2j803RnfaiIbFxjGdPIac8vHHpMmelwStYm0om_szvX7xc=@wuille.net>
 <75a02b16-0aac-4afd-1a9e-f71a8396baea@cronosurf.com>
In-Reply-To: <75a02b16-0aac-4afd-1a9e-f71a8396baea@cronosurf.com>
From: Marek Palatinus <marek@palatinus.cz>
Date: Tue, 31 Aug 2021 09:47:26 +0100
Message-ID: <CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com>
To: ts <ts@cronosurf.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ffc23605cad7014a"
Subject: Re: [bitcoin-dev] Human readable checksum (verification code) to
 avoid errors on BTC public addresses
Precedence: list

--000000000000ffc23605cad7014a
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000ffc23605cad7014a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I fully agree with sipa and his reasoning that this p=
roposal is not solving any particular problem, but making it actually a bit=
 worse.<br></div><div><br></div><div>Also, do you know what I hate more tha=
n copy&amp;pasting bitcoin addresses? Copy pasting zillion random fields fo=
r SEPA/wire transfers. And I believe that a single copy pasta of a bitcoin =
address is a much better user experience after all.</div><div><br></div><di=
v>Best,</div><div>slush<br></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 31, 2021 at 9:08 AM ts via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Pieter, thanks for your comments. Here my =
thoughts:<br>
<br>
Pieter Wuille wrote on 8/29/21 9:24 AM:<br>
&gt; On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt;&gt; Following up on my original proposal, I would like to get some mor=
e feedback of the community<br>
&gt;&gt;<br>
&gt;&gt; to see if this could be realized at some point. Also, any recommen=
dations as to who to contact<br>
&gt;&gt;<br>
&gt;&gt; to get things rolling?<br>
&gt; <br>
&gt; I honestly don&#39;t understand the point of what you&#39;re suggestin=
g.<br>
<br>
It is about creating a simple technical assistance that makes it more user =
friendly and less <br>
error prone to verify the entered address. For all types of users, includin=
g those who are <br>
less tech savvy.<br>
<br>
<br>
&gt; * If you&#39;re concerned about random typos, this is something alread=
y automatically protected against through the checksum (both base58check or=
 bech32/bech32m).<br>
<br>
I agree, but as mentioned in the original proposal, it is not about random =
typos (although <br>
this would help for other coins without integrated checksum of course), but=
 rather about <br>
copy&amp;paste errors (both technical or user caused).<br>
<br>
<br>
&gt; * If you&#39;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&#39;t even require the presence of a ch=
ecksum. Looking at the last N characters, or the middle N, or anything exce=
pt the first few, will do, and is just as good as an &quot;external&quot; c=
hecksum added at the end. For randomly-generated addresses (as honest ones =
are), each of those has exactly as much entropy.<br>
<br>
Correct. However, I believe that ADDITIONALLY to looking at N characters, a=
 quick check of a 3 <br>
or 4 digit code in bigger font next to the address would make for a better =
user experience. <br>
This gives the user the reassurance that there is definitely no error. I ag=
ree that most users <br>
with technical background including most of us here will routinely check th=
e first/last N <br>
characters. I usually check the first 3 + last 3 characters. But I don&#39;=
t think this is very <br>
user friendly. More importantly, I once had the case that two addresses wer=
e very similar at <br>
precisely those 6 characters, and only a more close and concentrated look m=
ade me see the <br>
difference. Moreover, some inexperienced users that are not aware of the co=
nsequences of <br>
entering a wrong address (much worse than entering the wrong bank account i=
n an online bank <br>
transfer) might forget to look at the characters altogether.<br>
<br>
<br>
&gt; * If you&#39;re concerned about maliciously constructed addresses, whi=
ch are designed to look similar in specific places, an attacker can just as=
 easily make the external checksum collide (and having one might even worse=
n this, as now the attacker can focus on exactly that, rather than needing =
to focus on every other character).<br>
<br>
Not so concerned about this case, since this is a very special case that ca=
n only occur under <br>
certain circumstances. But taking this case also into consideration, this i=
s why the user <br>
should use the verification code ADDITIONALLY to the normal way of verifyin=
g, not instead. If <br>
the attacker only focuses on the verification code, he will only be success=
ful with users that <br>
ONLY look at this code. But if the attacker intends to be more successful, =
he now needs to <br>
create a valid address that is both similar in specific places AND produces=
 the same <br>
verification code, which is way more difficult to achieve.<br>
<br>
<br>
&gt; Things would be different if you&#39;d suggest a checksum in another m=
edium than text (e.g. a visual/drawing/colorcoding one). But I don&#39;t se=
e any added value for an additional text-based checksum when addresses are =
already text themselves.<br>
<br>
Yes, a visual checksum could also work. Christopher Allen proposed to use L=
ifeHash as an <br>
alternative. It would be a matter of balancing the more complex implementat=
ion and need of <br>
space in the app&#39;s layout with the usability and advantages of use. One=
 advantage of the digit <br>
verification code is that it can be spoken in a call or written in a messag=
e.<br>
<br>
&gt; This is even disregarding the difficulty of getting the ecosystem to a=
dopt such changes.<br>
<br>
No changes are needed, only an agreement or recommendation on which algorit=
hm for the code <br>
generation should be used. Once this is done, it is up to the developers of=
 wallets and <br>
exchanges to implement this feature as they see fit.<br>
<br>
Greetings,<br>
TS<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ffc23605cad7014a--