From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 60762C000E for ; 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 ; 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 ; 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 ; Tue, 31 Aug 2021 08:48:05 +0000 (UTC) Received: by mail-lj1-x232.google.com with SMTP id i28so30435470ljm.7 for ; 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: <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 Date: Tue, 31 Aug 2021 09:47:26 +0100 Message-ID: To: ts , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.

Also, do you know what I hate more tha= n copy&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.

Best,
slush

On Tue, Aug 31, 2021 at 9:08 AM ts via bit= coin-dev <bitco= in-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 <bitc= oin-dev@lists.linuxfoundation.org> wrote:
>
>> Following up on my original proposal, I would like to get some mor= e feedback of the community
>>
>> to see if this could be realized at some point. Also, any recommen= dations as to who to contact
>>
>> to get things rolling?
>
> I honestly don't understand the point of what you're suggestin= g.

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, includin= g those who are
less tech savvy.


> * If you're concerned about random typos, this is something alread= y 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 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 "external" c= hecksum 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 ag= ree that most users
with technical background including most of us here will routinely check th= e 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 wer= e very similar at
precisely those 6 characters, and only a more close and concentrated look m= ade me see the
difference. Moreover, some inexperienced users that are not aware of the co= nsequences of
entering a wrong address (much worse than entering the wrong bank account i= n an online bank
transfer) might forget to look at the characters altogether.


> * If you'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).

Not so concerned about this case, since this is a very special case that ca= n only occur under
certain circumstances. But taking this case also into consideration, this i= s why the user
should use the verification code ADDITIONALLY to the normal way of verifyin= g, not instead. If
the attacker only focuses on the verification code, he will only be success= ful 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 m= edium than text (e.g. a visual/drawing/colorcoding one). But I don't se= e 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 L= ifeHash as an
alternative. It would be a matter of balancing the more complex implementat= ion 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 messag= e.

> This is even disregarding the difficulty of getting the ecosystem to a= dopt such changes.

No changes are needed, only an agreement or recommendation on which algorit= hm 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/mail= man/listinfo/bitcoin-dev
--000000000000ffc23605cad7014a--