Re: [bitcoin-dev] Base64-encoded descriptors
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 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 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 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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Base64-encoded descriptors
Hey Chris, Chris Belcher via bitcoin-dev 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@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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Base64-encoded descriptors
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Base64-encoded descriptors
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
Re: [bitcoin-dev] Base64-encoded descriptors
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Base64-encoded descriptors
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
