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 t
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 w
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 er
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 a
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. T
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
