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