path: root/f8/ac0e855d5cbe6a369c3cbc3c0a48398faae883

Return-Path: <marek@palatinus.cz>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 60762C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 08:48:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 41BFB60BBA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 08:48:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level: 
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=palatinus-cz.20150623.gappssmtp.com
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 BH_bNl7iiKJB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 08:48:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com
 [IPv6:2a00:1450:4864:20::232])
 by smtp3.osuosl.org (Postfix) with ESMTPS id DF14060A57
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 08:48:05 +0000 (UTC)
Received: by mail-lj1-x232.google.com with SMTP id i28so30435470ljm.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Aug 2021 01:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=palatinus-cz.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=JR+6bNwGr1vJGgX/bnNqipgtxvx02nbSPhO3V/AaNnE=;
 b=cqT1gF0I2rcp6KJPkmsaFZQDWSqkUMSjF/p4u81NgJOX100VmlMVuWpUMZfqy75bzZ
 SPy2kmhqOjrz9FKrdVrpephBleLPplmy7NIkYf4wCR4FS+6Opq/HLHWDn2Y9YL6kuj3w
 Zs1pt6R1BbLGYIbgnE1nq0C0zvcjXR2CmTEWG8XCXaNdd9Mazp4vCH9Yu/pXLQGTAmSw
 R5s4nvRrAycjLeqHUF13BXK+3KtzXBzxGnWwuP27JDmAIyjvFLmkLnNmMyxo25unp79r
 Esl8avzQE5lOp5A0ELEI9Gtn30BkYHHXSp69Mo8nDbgo3e15zLoKQvW4QBQMON2CxnR9
 m/Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=JR+6bNwGr1vJGgX/bnNqipgtxvx02nbSPhO3V/AaNnE=;
 b=YaFXbTTWnlSsaPCNiANRoCoRxF0aIhrYDOXbA4Unn4LT2dQX9TGy4RPcpm5n/R4Sry
 2Q3Hz/YYLPiF776QIAsK/643qc4FmXoHmDTE+TyyJaDT1vCl4qotCWFRVBA+KeuhoMRM
 sSmJSAntxvOrxYObv9XxN+MFQbokjiIE8DT38SmmB12lb8EoBE2+cvIB3A4P3sye/XGS
 /nxwrvsBuWz0v+YTJCRxJ15FwJ8ejFCvVWF5UKXiHKRJylE9snlyxUF4f1w9fReBG5p0
 R+b5x78zIAn69ZFFHBhSbcjLulSibRbTtzhJkxj4g5e690oIcXhIfFaBrLFLrMZ5riyq
 CDZw==
X-Gm-Message-State: AOAM531sXZd1/veeFGeZo9vRoxbScXmZUm3HhO1hluMgAgb8zyxOOdzC
 wUKkKItUcO/SZfUpwuqwlLMSxLXG3KkG8eRDx602eAyFuPjCpQ==
X-Google-Smtp-Source: ABdhPJxXruUQ/m3DxZrH/+0CxsJaOMW5CNG1UYZgUMJTjC9Vw8P/x/g9zFro8BsXE591ANU4qZWKF/7oU0Zb0v+K3CA=
X-Received: by 2002:a05:651c:3c8:: with SMTP id
 f8mr24053715ljp.213.1630399683863; 
 Tue, 31 Aug 2021 01:48:03 -0700 (PDT)
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2021 08:48:10 -0000

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