diff options
| author | Marek Palatinus <marek@palatinus.cz> | 2021-08-31 09:47:26 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-08-31 08:48:10 +0000 |
| commit | 72693cba44e8f4151b11b0d6b99a0ba6b47b769b (patch) | |
| tree | 634545acb2f6e8e18188e990d7204552915aec72 | |
| parent | 60696aa0d37fa2b5875374fdf8948ed64b1e3c44 (diff) | |
| download | pi-bitcoindev-72693cba44e8f4151b11b0d6b99a0ba6b47b769b.tar.gz pi-bitcoindev-72693cba44e8f4151b11b0d6b99a0ba6b47b769b.zip | |
Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses
| -rw-r--r-- | f8/ac0e855d5cbe6a369c3cbc3c0a48398faae883 | 357 |
1 files changed, 357 insertions, 0 deletions
diff --git a/f8/ac0e855d5cbe6a369c3cbc3c0a48398faae883 b/f8/ac0e855d5cbe6a369c3cbc3c0a48398faae883 new file mode 100644 index 000000000..4cb822b07 --- /dev/null +++ b/f8/ac0e855d5cbe6a369c3cbc3c0a48398faae883 @@ -0,0 +1,357 @@ +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&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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco= +in-dev@lists.linuxfoundation.org</a>> 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> +> On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev <<a h= +ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc= +oin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> <br> +>> Following up on my original proposal, I would like to get some mor= +e feedback of the community<br> +>><br> +>> to see if this could be realized at some point. Also, any recommen= +dations as to who to contact<br> +>><br> +>> to get things rolling?<br> +> <br> +> I honestly don't understand the point of what you'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> +> * If you'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&paste errors (both technical or user caused).<br> +<br> +<br> +> * 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.<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'= +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> +> * 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).<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> +> 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.<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'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> +> 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-- + |