Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 037B3C000E for ; 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 ; 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 ; 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 ; Sat, 3 Jul 2021 14:01:03 +0000 (UTC) Received: by mail-io1-xd35.google.com with SMTP id y76so15283772iof.6 for ; 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> <20210703100540.pr3nsgjhox26hhic@ganymede> In-Reply-To: <20210703100540.pr3nsgjhox26hhic@ganymede> From: Craig Raw Date: Sat, 3 Jul 2021 16:00:51 +0200 Message-ID: To: "David A. Harding" Content-Type: multipart/alternative; boundary="000000000000a946d005c63880af" X-Mailman-Approved-At: Sat, 03 Jul 2021 15:06:30 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
It's a consideration, not a serious concern.

<= /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's difficult to reduce this to a mathematical argument, as is t= rue for many UX considerations. Your example in fixed width here:=C2=A0h= ttps://gist.github.com/craigraw/fc98b9031a7e01e1bc5d75a77bdb72e5
<= 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 "h". Thanks for the detailed reply.
<= br>
Craig

On Sat, Jul 3, 2021 at 12:11 PM David A. Harding &= lt;dave@dtrt.org> wrote:
<= 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:
> There is a downside to using "h"/"H" from a UX per= spective - taking up more
> space

Is this a serious concern of yours?=C2=A0 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.

=C2=A0 =C2=A0 pkh([d34db33f/44h/0h/0h]xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed5= 4G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL/= 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&= quot; with
any arabic numeral.=C2=A0 Second, avoiding transcription errors is exactly<= br> 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.=C2=A0 (= And
you can argue that h is better since it's part of both the base58check<= br> 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<= br> 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.=C2=A0 (And I've personally lost time to that class of problems.)= =C2=A0 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.=C2=A0 I think these problems are much more serio= us
than using a tiny bit of extra space in a GUI or on a physical backup
medium.

-Dave
--000000000000a946d005c63880af--