[bitcoin-dev] Base64-encoded descriptors

[bitcoin-dev] Base64-encoded descriptors

[Chris Belcher]

I've recently been playing around with descriptors, and they are very
nice to work with. They should become the standard for master public
keys IMO.

One downside is that users cant easily copypaste them to-and-fro to make
watch-only wallet. The descriptors contain parenthesis and commas which
stop highlighting by double-clicking. Also the syntax might look scary
to newbs.

An obvious solution is to base64 encode the descriptors. Then users
would get a text blog as the master public key without any extra details
to bother them, and developers can easily base64 decode for developing
with them.

A complication might be the descriptor checksum. If there's a typo in
the base64 text then that could decode into multiple character errors in
the descriptor, which might be problematic for the checksum. Maybe the
descriptor could be base64 encoded without the checksum, then attach the
checksum to the end of the base64 text.

Thoughts?

I didn't come up with these ideas, they came from discussions with achow101.

Re: [bitcoin-dev] Base64-encoded descriptors

[Spencer Dupre`]

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

Sounds like a good UX improvement, but do we really need to introduce a new
encoding? Perhaps bech32 could be used instead.

On Tue, Dec 24, 2019, 12:07 PM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've recently been playing around with descriptors, and they are very
> nice to work with. They should become the standard for master public
> keys IMO.
>
> One downside is that users cant easily copypaste them to-and-fro to make
> watch-only wallet. The descriptors contain parenthesis and commas which
> stop highlighting by double-clicking. Also the syntax might look scary
> to newbs.
>
> An obvious solution is to base64 encode the descriptors. Then users
> would get a text blog as the master public key without any extra details
> to bother them, and developers can easily base64 decode for developing
> with them.
>
> A complication might be the descriptor checksum. If there's a typo in
> the base64 text then that could decode into multiple character errors in
> the descriptor, which might be problematic for the checksum. Maybe the
> descriptor could be base64 encoded without the checksum, then attach the
> checksum to the end of the base64 text.
>
> Thoughts?
>
> I didn't come up with these ideas, they came from discussions with
> achow101.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Base64-encoded descriptors

[Trey Del Bonis]

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

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.

QR codes (as Pavol mentioned) have built-in error detection (using its own
BCH code scheme), somewhat mitigate this when used there.  Although
personally I'm skeptical of how useful payment descriptors are for the
kinds of quick transactions that QR codes work well for.

-Trey

On Tue, Dec 24, 2019, 6:55 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 Tue, Dec 24, 2019, 12:07 PM Chris Belcher via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I've recently been playing around with descriptors, and they are very
>> nice to work with. They should become the standard for master public
>> keys IMO.
>>
>> One downside is that users cant easily copypaste them to-and-fro to make
>> watch-only wallet. The descriptors contain parenthesis and commas which
>> stop highlighting by double-clicking. Also the syntax might look scary
>> to newbs.
>>
>> An obvious solution is to base64 encode the descriptors. Then users
>> would get a text blog as the master public key without any extra details
>> to bother them, and developers can easily base64 decode for developing
>> with them.
>>
>> A complication might be the descriptor checksum. If there's a typo in
>> the base64 text then that could decode into multiple character errors in
>> the descriptor, which might be problematic for the checksum. Maybe the
>> descriptor could be base64 encoded without the checksum, then attach the
>> checksum to the end of the base64 text.
>>
>> Thoughts?
>>
>> I didn't come up with these ideas, they came from discussions with
>> achow101.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Base64-encoded descriptors

[Pavol Rusnak]

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

I'd rather see something using Base58 or even better Bech32. Base64 is not
URL/QR code friendly.

On Tue, Dec 24, 2019, 18:06 Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've recently been playing around with descriptors, and they are very
> nice to work with. They should become the standard for master public
> keys IMO.
>
> One downside is that users cant easily copypaste them to-and-fro to make
> watch-only wallet. The descriptors contain parenthesis and commas which
> stop highlighting by double-clicking. Also the syntax might look scary
> to newbs.
>
> An obvious solution is to base64 encode the descriptors. Then users
> would get a text blog as the master public key without any extra details
> to bother them, and developers can easily base64 decode for developing
> with them.
>
> A complication might be the descriptor checksum. If there's a typo in
> the base64 text then that could decode into multiple character errors in
> the descriptor, which might be problematic for the checksum. Maybe the
> descriptor could be base64 encoded without the checksum, then attach the
> checksum to the end of the base64 text.
>
> Thoughts?
>
> I didn't come up with these ideas, they came from discussions with
> achow101.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Base64-encoded descriptors

[William Casarin]

Hey Chris,

Chris Belcher via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> I've recently been playing around with descriptors, and they are very
> nice to work with. They should become the standard for master public
> keys IMO.
>
> One downside is that users cant easily copypaste them to-and-fro to make
> watch-only wallet. The descriptors contain parenthesis and commas which
> stop highlighting by double-clicking. Also the syntax might look scary
> to newbs.
>
> An obvious solution is to base64 encode the descriptors. Then users
> would get a text blog as the master public key without any extra details
> to bother them, and developers can easily base64 decode for developing
> with them.

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.

> I didn't come up with these ideas, they came from discussions with achow101.

I suggested base58 or base62 +hrp for PSBT in id:87zhzlbfq5.fsf@jb55.com
[1] for the reasons that you mentioned, 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. In this case,
encoding of any kind doesn't make much sense IMO.

Cheers,
Will

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016151.html


-- 
https://jb55.com

Re: [bitcoin-dev] Base64-encoded descriptors

[Andrew Chow]

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