path: root/87/070640660db6af3ed7ca5761841d4545a069ef

Return-Path: <craigraw@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 037B3C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 14:01:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id DD74360745
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 14:01:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.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 wtHWmn1SynK2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 14:01:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com
 [IPv6:2607:f8b0:4864:20::d35])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A2C8260710
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Jul 2021 14:01:03 +0000 (UTC)
Received: by mail-io1-xd35.google.com with SMTP id y76so15283772iof.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Jul 2021 07:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=jbVVDZBOgnI7si7PdzkWXa39vVbafNW/FlsK0OOl52k=;
 b=UT9xph6f7llYnIUUZiqNxf9GlNozyiMfS3K1Iv+Xk89Ik+TcB+agI6C6UPaiC48h8O
 YqbVB/2mLD5EzD2ayN2Cl4Zq3mhizbipDFgom1mtnJ+YN+zIc4QcHNctceHKYKEZ5myv
 m1nidKJQPLOiW771SbYJyEWs3evw/IAC7nOn0/nR8uvEHBN8mNS+9T4ij8MmoD/iqDJZ
 qX0v6j9QNltilhgH9JuyEze8TdCE86qDf8crJlhO+OPwhuURS1V9GDhMGyyy5FU74CQt
 K/TV8Danv3mxYWatP3cCbI0Jm5NtBbUMGABNVkNTIoNtN4+J/w0ErWedNfp1SfClD5Gu
 GWXg==
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=jbVVDZBOgnI7si7PdzkWXa39vVbafNW/FlsK0OOl52k=;
 b=lz1Qhx8ZhQ+lHyLxbnINNHj0G1KEXpCYziAspkqd8nEw8VB8cwT7BSNA1vVJB7XqpC
 Gyi14BcnvhM42/SyNr/QTUrNKlHGceq9rojc5I8lA2eYDg5mjgy+4cPa0f+8h4aG5SpN
 JU2XRt6dRLW4EcMoim93y9wmHidR53CdZYqpaj5OQHzco65shPdNYPQr5y9JNurEMdrp
 UBFV9SHOORnq7r6myyrXYn7YC/9jM1Z/jxPBxfvEL7eLxtKww15SCzof+VvAFmTPY6tW
 nmbZm5JbJg4w31diaWA0Sdn8qtq0wdquAQUTgvyuW1J5zSaW1YZcCZBIagRZ4udp/rn1
 xNRg==
X-Gm-Message-State: AOAM532vxYFMUOmvghtiOzsJ6GCeBWddgBSv6Gz+Wm+CiH4C1I1kO81V
 8F7Ey1hrsmJHi1GYO8IxXPKh2WQ39axNGFOSKTowjLUPiUc=
X-Google-Smtp-Source: ABdhPJyB1nDMxnFO7ydQgVpQ7cRv2Hf312R1zB1l2crdmqzJSjJ4IITw9Kicq2DQY2bfx6yNmOXESN7uU4LXQYiC054=
X-Received: by 2002:a6b:b2c4:: with SMTP id b187mr4244975iof.206.1625320862597; 
 Sat, 03 Jul 2021 07:01:02 -0700 (PDT)
MIME-Version: 1.0
References: <1eb7b635-094c-a583-7dc0-21cea58ed1fb@achow101.com>
 <20210703032405.j3mru5rbag5sbfil@ganymede>
 <ad7657ea-0c35-f065-1788-cc8663bf94b5@achow101.com>
 <CAPR5oBP+5r8WLOew6zOdp3BzOLNr0vf2SVK028zfgoCSyu2wnA@mail.gmail.com>
 <20210703100540.pr3nsgjhox26hhic@ganymede>
In-Reply-To: <20210703100540.pr3nsgjhox26hhic@ganymede>
From: Craig Raw <craigraw@gmail.com>
Date: Sat, 3 Jul 2021 16:00:51 +0200
Message-ID: <CAPR5oBMnzzNxL1j5YRgJNLnC9aPTX0m=As23KB2Wf-UDahL40A@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="000000000000a946d005c63880af"
X-Mailman-Approved-At: Sat, 03 Jul 2021 15:06:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
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: Sat, 03 Jul 2021 14:01:05 -0000

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

It's a consideration, not a serious concern.

When I made the point around alphanumeric characters being similar to the
path numbers, I was actually thinking of the output descriptor appearing in
a fixed character width font, which I prefer as more appropriate for
displaying hexidecimal values. In this case, the apostrophe provides more
whitespace which makes the path easier to parse visually. It's difficult to
reduce this to a mathematical argument, as is true for many UX
considerations. Your example in fixed width here:
https://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5

That said you make good arguments around the shell quoting and stamps for
metal backups, and therefore I agree it is preferable to use the lowercase
"h". Thanks for the detailed reply.

Craig

On Sat, Jul 3, 2021 at 12:11 PM David A. Harding <dave@dtrt.org> wrote:

> On Sat, Jul 03, 2021 at 10:35:48AM +0200, Craig Raw wrote:
> > There is a downside to using "h"/"H" from a UX perspective - taking up
> more
> > space
>
> Is this a serious concern of yours?  An apostrophe is 1/2 en; an "h" is
> 1 en; the following descriptor contains three hardened derivations in 149
> characters; assuming the average non-'/h character width is 1.5 en, the
> difference between 207 en and 208.5 en is barely more than half a
> percent.
>
>
> pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/1/*)#ml40v0wf
>
> Here's a direct visual comparison:
> https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80
>
> > appearing as alphanumeric characters similar to the path numbers
>
> First, I think you'd have to be using an awful font to confuse "h" with
> any arabic numeral.  Second, avoiding transcription errors is exactly
> why descriptors now have checksums.
>
> > they make derivation paths and descriptors more difficult to read.
>
> The example descriptor pasted above looks equally (un)readable to me
> whether it uses ' or h.
>
> > Also, although not as important, less efficient when making metal
> > backups.
>
> I think many metal backup schemes are using stamps or punch grids that
> are fixed-width in nature, so there's no difference either way.  (And
> you can argue that h is better since it's part of both the base58check
> and bech32 character sets, so you already need a stamp or a grid row for
> it---but ' is otherwise unused, so a stamp or grid row for it would be
> special).
>
> But even if people are manually etching descriptors into metal, we're
> back to the original point where we're looking at something like a 0.7%
> difference in "efficiency".
>
> By comparison, the Bitcoin Core issue I cited in my earlier post
> contains several examples of actual users needing technical support
> because they tried to use '-containing descriptors in a bourne-style
> shell.  (And I've personally lost time to that class of problems.)  In
> the worst case, a shell-quoting accident can cause loss of money by
> sending bitcoins to the descriptor for a key your hardware signing
> device won't sign for.  I think these problems are much more serious
> than using a tiny bit of extra space in a GUI or on a physical backup
> medium.
>
> -Dave
>

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

<div dir=3D"ltr">It&#39;s a consideration, not a serious concern.<div><br><=
/div><div>When I made the point around alphanumeric characters being simila=
r to the path numbers, I was actually thinking of the output descriptor app=
earing in a fixed character width font, which=C2=A0I prefer as more appropr=
iate for displaying=C2=A0hexidecimal=C2=A0values. In this case, the apostro=
phe provides more whitespace which=C2=A0makes the path easier to parse visu=
ally. It&#39;s difficult to reduce this to a mathematical argument, as is t=
rue for many UX considerations. Your example in fixed width here:=C2=A0<a h=
ref=3D"https://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5">h=
ttps://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5</a></div><=
div><br></div><div>That said you make good arguments around the shell quoti=
ng and stamps for metal backups, and therefore I agree it is preferable to =
use the lowercase &quot;h&quot;. Thanks for the detailed reply.</div><div><=
br></div><div>Craig</div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Sat, Jul 3, 2021 at 12:11 PM David A. Harding &=
lt;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jul 03, 2021 at 10=
:35:48AM +0200, Craig Raw wrote:<br>
&gt; There is a downside to using &quot;h&quot;/&quot;H&quot; from a UX per=
spective - taking up more<br>
&gt; space <br>
<br>
Is this a serious concern of yours?=C2=A0 An apostrophe is 1/2 en; an &quot=
;h&quot; is<br>
1 en; the following descriptor contains three hardened derivations in 149<b=
r>
characters; assuming the average non-&#39;/h character width is 1.5 en, the=
<br>
difference between 207 en and 208.5 en is barely more than half a<br>
percent.<br>
<br>
=C2=A0 =C2=A0 pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed5=
4G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/=
1/*)#ml40v0wf<br>
<br>
Here&#39;s a direct visual comparison: <a href=3D"https://gist.github.com/h=
arding/2fbbf2bfdce04c3e4110082f03ae3c80" rel=3D"noreferrer" target=3D"_blan=
k">https://gist.github.com/harding/2fbbf2bfdce04c3e4110082f03ae3c80</a><br>
<br>
&gt; appearing as alphanumeric characters similar to the path numbers<br>
<br>
First, I think you&#39;d have to be using an awful font to confuse &quot;h&=
quot; with<br>
any arabic numeral.=C2=A0 Second, avoiding transcription errors is exactly<=
br>
why descriptors now have checksums.<br>
<br>
&gt; they make derivation paths and descriptors more difficult to read.<br>
<br>
The example descriptor pasted above looks equally (un)readable to me<br>
whether it uses &#39; or h.<br>
<br>
&gt; Also, although not as important, less efficient when making metal<br>
&gt; backups.<br>
<br>
I think many metal backup schemes are using stamps or punch grids that<br>
are fixed-width in nature, so there&#39;s no difference either way.=C2=A0 (=
And<br>
you can argue that h is better since it&#39;s part of both the base58check<=
br>
and bech32 character sets, so you already need a stamp or a grid row for<br=
>
it---but &#39; is otherwise unused, so a stamp or grid row for it would be<=
br>
special).<br>
<br>
But even if people are manually etching descriptors into metal, we&#39;re<b=
r>
back to the original point where we&#39;re looking at something like a 0.7%=
<br>
difference in &quot;efficiency&quot;.<br>
<br>
By comparison, the Bitcoin Core issue I cited in my earlier post<br>
contains several examples of actual users needing technical support<br>
because they tried to use &#39;-containing descriptors in a bourne-style<br=
>
shell.=C2=A0 (And I&#39;ve personally lost time to that class of problems.)=
=C2=A0 In<br>
the worst case, a shell-quoting accident can cause loss of money by<br>
sending bitcoins to the descriptor for a key your hardware signing<br>
device won&#39;t sign for.=C2=A0 I think these problems are much more serio=
us<br>
than using a tiny bit of extra space in a GUI or on a physical backup<br>
medium.<br>
<br>
-Dave<br>
</blockquote></div>

--000000000000a946d005c63880af--