path: root/88/e9f81431668ee2c4e9c397bc9f75fe888c7ac0

Return-Path: <ts@cronosurf.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7DEBAC000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 05:08:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 62E6E400C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 05:08:53 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.803
X-Spam-Level: 
X-Spam-Status: No, score=0.803 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Ohfji5SSU4yA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 05:08:51 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from premium29-m.web-hosting.com (premium29-m.web-hosting.com
 [68.65.120.189])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 62087400C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Sep 2021 05:08:51 +0000 (UTC)
Received: from [189.172.114.216] (port=58864 helo=[192.168.1.109])
 by premium29.web-hosting.com with esmtpsa (TLS1.2) tls
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2)
 (envelope-from <ts@cronosurf.com>)
 id 1mM1RU-00Bwrl-TS; Fri, 03 Sep 2021 01:08:50 -0400
To: Marek Palatinus <marek@palatinus.cz>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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>
 <CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com>
From: ts <ts@cronosurf.com>
Message-ID: <e81a1400-2b3a-bdeb-ccfd-6aad56c09785@cronosurf.com>
Date: Fri, 3 Sep 2021 00:08:42 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------A97D6C963E4AEE573A9EE50D"
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - premium29.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - cronosurf.com
X-Get-Message-Sender-Via: premium29.web-hosting.com: authenticated_id:
 ts@cronosurf.com
X-Authenticated-Sender: premium29.web-hosting.com: ts@cronosurf.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
X-Mailman-Approved-At: Fri, 03 Sep 2021 08:20:20 +0000
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: Fri, 03 Sep 2021 05:08:53 -0000

This is a multi-part message in MIME format.
--------------A97D6C963E4AEE573A9EE50D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Marek,

Marek Palatinus wrote on 8/31/21 3:47 AM:
> I fully agree with sipa and his reasoning that this proposal is not solving any particular 
> problem, but making it actually a bit worse.
Ok, I understand. I'm just trying to find ways to reduce the risk of sending to the wrong 
address and to make the transaction process a bit more user friendly, specially for 
inexperienced users. I am sure that it can be implemented in a way without making it "worse". 
For example, if there is the risk that the user looks ONLY at the code and not at the address, 
then the code should have enough entropy to account for it. If looking at 6 characters is 
considered to be enough, then the code should also be 6 characters long. As I mentioned in my 
following message, the code could be made from specific characters of the address instead of a 
checksum (e.g. first 4 and last 2 characters). By showing these characters to the user 
separately and in a bigger font, he will be encouraged to verify all of these characters.

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

I totally agree with this :)

Cheers,
TS


> Best,
> slush
>
> On Tue, Aug 31, 2021 at 9:08 AM ts via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org 
> <mailto: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 <mailto: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 <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>

--------------A97D6C963E4AEE573A9EE50D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="monospace">Hi Marek,</font></p>
    <div class="moz-cite-prefix"><font face="monospace">Marek Palatinus
        wrote on 8/31/21 3:47 AM:<br>
      </font></div>
    <blockquote type="cite"
cite="mid:CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div><font face="monospace">I fully agree with sipa and his
            reasoning that this proposal is not solving any particular
            problem, but making it actually a bit worse.<br>
          </font></div>
      </div>
    </blockquote>
    <font face="monospace">Ok, I understand. I'm just trying to find
      ways to reduce the risk of sending to the wrong address and to
      make the transaction process a bit more user friendly, specially
      for inexperienced users. I am sure that it can be implemented in a
      way without making it "worse". For example, if there is the risk
      that the user looks ONLY at the code and not at the address, then
      the code should have enough entropy to account for it. If looking
      at 6 characters is considered to be enough, then the code should
      also be 6 characters long. As I mentioned in my following message,
      the code could be made from specific characters of the address
      instead of a checksum (e.g. first 4 and last 2 characters). By
      showing these characters to the user separately and in a bigger
      font, he will be encouraged to verify all of these characters.<br>
      <br>
    </font>
    <blockquote type="cite"
cite="mid:CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com">
      <div dir="ltr">
        <div><font face="monospace">Also, do you know what I hate more
            than copy&amp;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.</font></div>
      </div>
    </blockquote>
    <p><font face="monospace">I totally agree with this :)</font></p>
    <font face="monospace">
    </font>
    <p><font face="monospace">Cheers,<br>
        TS</font></p>
    <p><font face="monospace"><br>
      </font></p>
    <blockquote type="cite"
cite="mid:CAJna-Hhtr0v_uEE-4ET4FPNnGnPv8sW2JXkVka0XDkphy_YmSg@mail.gmail.com">
      <div dir="ltr">
        <div>Best,</div>
        <div>slush<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Tue, Aug 31, 2021 at 9:08
          AM ts via bitcoin-dev &lt;<a
            href="mailto:bitcoin-dev@lists.linuxfoundation.org"
            moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(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
            href="mailto:bitcoin-dev@lists.linuxfoundation.org"
            target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;
          wrote:<br>
          &gt; <br>
          &gt;&gt; Following up on my original proposal, I would like to
          get some more feedback of the community<br>
          &gt;&gt;<br>
          &gt;&gt; to see if this could be realized at some point. Also,
          any recommendations as to who to contact<br>
          &gt;&gt;<br>
          &gt;&gt; to get things rolling?<br>
          &gt; <br>
          &gt; I honestly don't understand the point of what you're
          suggesting.<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, including those who are <br>
          less tech savvy.<br>
          <br>
          <br>
          &gt; * If you're concerned about random typos, this is
          something already 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'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.<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 agree that most users <br>
          with technical background including most of us here will
          routinely check the 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 were very similar at <br>
          precisely those 6 characters, and only a more close and
          concentrated look made me see the <br>
          difference. Moreover, some inexperienced users that are not
          aware of the consequences of <br>
          entering a wrong address (much worse than entering the wrong
          bank account in an online bank <br>
          transfer) might forget to look at the characters altogether.<br>
          <br>
          <br>
          &gt; * 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).<br>
          <br>
          Not so concerned about this case, since this is a very special
          case that can only occur under <br>
          certain circumstances. But taking this case also into
          consideration, this is why the user <br>
          should use the verification code ADDITIONALLY to the normal
          way of verifying, not instead. If <br>
          the attacker only focuses on the verification code, he will
          only be successful 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'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.<br>
          <br>
          Yes, a visual checksum could also work. Christopher Allen
          proposed to use LifeHash as an <br>
          alternative. It would be a matter of balancing the more
          complex implementation 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 message.<br>
          <br>
          &gt; This is even disregarding the difficulty of getting the
          ecosystem to adopt such changes.<br>
          <br>
          No changes are needed, only an agreement or recommendation on
          which algorithm 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="mailto:bitcoin-dev@lists.linuxfoundation.org"
            target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a><br>
          <a
            href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>

--------------A97D6C963E4AEE573A9EE50D--