From: Andrew Chow <achow101-lists@achow101•com>
To: William Casarin <jb55@jb55•com>,
Spencer Dupre` <spencer.dupre@gmail•com>,
Chris Belcher <belcher@riseup•net>,
Trey Del Bonis <j.delbonis.3@gmail•com>,
Pavol Rusnak <stick@satoshilabs•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Base64-encoded descriptors
Date: Thu, 26 Dec 2019 05:18:00 +0000 [thread overview]
Message-ID: <60e86243-8aa7-8b67-1547-9114d6f1f1cd@achow101.com> (raw)
In-Reply-To: <87sgl8mijl.fsf@jb55.com>
Hi All,
Just a few comments about choosing an encoding and why this is even
being proposed.
On Wednesday, December 25, 2019 12:17 PM, William Casarin via
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> I don't think encoding descriptors is a good idea. Encoding makes more
> sense if it's non-human-readable binary data that you want transfer
> over
> a plaintext channel.
>
> Descriptors aren't binary data, and have a wealth of useful
> information
> that you can view at a glance. Obfuscating this information just to
> gain
> the ability to copy-paste doesn't seem like a good idea.
The main reasons this was proposed in the first place is because of
concerns that users will be unwilling to use or be confused by descriptors.
There is a concern that users will not understand the commas,
parentheses, brackets, etc. syntax of descriptors and thus only copy
part of it.
There is also the concern that users will see this code-like syntax and
be intimidated by it so they will not want to handle them.
So my (offhanded) suggestion was to encode it in some way to just make
it look like some magic string that they need to handle as one unit.
> so I'm a bit sad that base64 was
> chosen. base64 isn't really good for double-click copy-pasting, it
> contains characters such as +/= which aren't always included when
> double-clicking. I prefer bech32, base58 or base62.
On Tuesday, December 24, 2019 2:09 PM, Spencer Dupre` via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Sounds like a good UX improvement, but do we really need to introduce
a new encoding? Perhaps bech32 could be used instead.
On Tuesday, December 24, 2019 2:25 PM, Pavol Rusnak via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I'd rather see something using Base58 or even better Bech32. Base64 is
not URL/QR code friendly.
A different encoding scheme could certainly be used. Base64 was
suggested in my comments to Chris and others as it is a well known
encoding scheme that doesn't already define its own checksum as Base58
and Bech32 do. This is an important detail because descriptors *also*
have their own checksum scheme.
While other encoding methods could be used, I do want to point out that
it would be nice to stick to things that already exist. We could use a
bech32-like encoding, just with the different BCH code that descriptors
use instead of the bech32 code, but calling that bech32 would be a bit
confusing. And I don't think we should use Base58 at all.
On Tuesday, December 24, 2019 8:02 PM, Trey Del Bonis via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Part of the aversion to using bech32 may be that the BCH code used in
> bech32 for error detection doesn't hold up for messages longer than
> some length (that I can't remember off the top of my head). It still
> encodes and decodes perfectly well but a decoder won't be guaranteed
> to detect potential errors, so that's somewhat wasted there. Maybe
> someone should define a derivatives of bech32 that retains error
> detection properties for longer message lengths, such as those used in
> lightning invoices.
Descriptors already have their own BCH code for descriptor checksums
optimized for their length and character rset. This can be repurposed to
be used with whatever encoding scheme is chosen so long as the
encoding's character set is covered by the descriptor checksum character
set. The checksum's character set is fairly large and covers all(?)
characters on a standard keyboard so that descriptors could be expanded
with other features in the future. Thus it should cover any encoding
scheme that is suggested.
More information about the descriptor checksum can be found at
https://github.com/bitcoin/bitcoin/blob/master/src/script/descriptor.cpp#L26
prev parent reply other threads:[~2019-12-26 5:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-24 17:06 Chris Belcher
2019-12-24 19:09 ` Spencer Dupre`
2019-12-25 1:02 ` Trey Del Bonis
2019-12-24 19:25 ` Pavol Rusnak
2019-12-25 17:17 ` William Casarin
2019-12-26 5:18 ` Andrew Chow [this message]
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=60e86243-8aa7-8b67-1547-9114d6f1f1cd@achow101.com \
--to=achow101-lists@achow101$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=j.delbonis.3@gmail$(echo .)com \
--cc=jb55@jb55$(echo .)com \
--cc=spencer.dupre@gmail$(echo .)com \
--cc=stick@satoshilabs$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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