* [bitcoin-dev] Base64-encoded descriptors
@ 2019-12-24 17:06 Chris Belcher
2019-12-24 19:09 ` Spencer Dupre`
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Chris Belcher @ 2019-12-24 17:06 UTC (permalink / raw)
To: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [bitcoin-dev] Base64-encoded descriptors 2019-12-24 17:06 [bitcoin-dev] Base64-encoded descriptors 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 2 siblings, 1 reply; 6+ messages in thread From: Spencer Dupre` @ 2019-12-24 19:09 UTC (permalink / raw) To: Chris Belcher, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Base64-encoded descriptors 2019-12-24 19:09 ` Spencer Dupre` @ 2019-12-25 1:02 ` Trey Del Bonis 0 siblings, 0 replies; 6+ messages in thread From: Trey Del Bonis @ 2019-12-25 1:02 UTC (permalink / raw) To: Spencer Dupre`, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Base64-encoded descriptors 2019-12-24 17:06 [bitcoin-dev] Base64-encoded descriptors Chris Belcher 2019-12-24 19:09 ` Spencer Dupre` @ 2019-12-24 19:25 ` Pavol Rusnak 2019-12-25 17:17 ` William Casarin 2 siblings, 0 replies; 6+ messages in thread From: Pavol Rusnak @ 2019-12-24 19:25 UTC (permalink / raw) To: Chris Belcher, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Base64-encoded descriptors 2019-12-24 17:06 [bitcoin-dev] Base64-encoded descriptors Chris Belcher 2019-12-24 19:09 ` Spencer Dupre` 2019-12-24 19:25 ` Pavol Rusnak @ 2019-12-25 17:17 ` William Casarin 2019-12-26 5:18 ` Andrew Chow 2 siblings, 1 reply; 6+ messages in thread From: William Casarin @ 2019-12-25 17:17 UTC (permalink / raw) To: Chris Belcher; +Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Base64-encoded descriptors 2019-12-25 17:17 ` William Casarin @ 2019-12-26 5:18 ` Andrew Chow 0 siblings, 0 replies; 6+ messages in thread From: Andrew Chow @ 2019-12-26 5:18 UTC (permalink / raw) To: William Casarin, Spencer Dupre`, Chris Belcher, Trey Del Bonis, Pavol Rusnak Cc: Bitcoin Protocol Discussion 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-12-26 5:18 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-24 17:06 [bitcoin-dev] Base64-encoded descriptors 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox