public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Craig Raw <craigraw@gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposals for Output Script Descriptors
Date: Sat, 3 Jul 2021 16:00:51 +0200	[thread overview]
Message-ID: <CAPR5oBMnzzNxL1j5YRgJNLnC9aPTX0m=As23KB2Wf-UDahL40A@mail.gmail.com> (raw)
In-Reply-To: <20210703100540.pr3nsgjhox26hhic@ganymede>

[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4083 bytes --]

  reply	other threads:[~2021-07-03 14:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 21:14 [bitcoin-dev] BIP Proposals for Output Script Descriptors Andrew Chow
2021-06-29 22:22 ` Christopher Allen
2021-06-29 22:35   ` Andrew Chow
     [not found] ` <CAD5xwhg9sno+aABgUtiwhBo8mLrmj5m9WowGjnUfv-f1pSbshw@mail.gmail.com>
2021-07-02 20:05   ` Andrew Chow
2021-07-03  3:24 ` David A. Harding
2021-07-03  5:12   ` Andrew Chow
2021-07-03  8:35     ` Craig Raw
2021-07-03 10:05       ` David A. Harding
2021-07-03 14:00         ` Craig Raw [this message]
2021-07-04 17:56           ` Daniel Bayerdorffer
2021-08-05 14:27 ` Sjors Provoost
2021-08-05 20:49   ` Christopher Allen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPR5oBMnzzNxL1j5YRgJNLnC9aPTX0m=As23KB2Wf-UDahL40A@mail.gmail.com' \
    --to=craigraw@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox