Descriptor::Bare(PkH) string encoding doesn't roundtrip, parsed as Descriptor::Pkh

[shesek]

Since Bare descriptors are encoded as just the inner miniscript with no explicit bare() wrapper, Bare descriptors over a PkH miniscript fragment and Pkh descriptors are both encoded as "pkh(KEY)", which always decodes back to a Pkh descriptor.

This isn't terrible because both are semantically equivalent, refer to the same scriptPubKey and can be satisfied using the same assets, but it is surprising and unexpected if you treat descriptor strings as a stable serialization format.

It seems that this conflict is inherent due to the reuse of pkh() for miniscripts/descriptors and the lack of an explicit bare() wrapper so I don’t really have a concrete suggestion, just thought it was worth bringing up.

[shesek]

_{(As an aside, I did find the reuse of pkh/pk/thresh/older/after/{sha,hash}256/{ripemd,hash}160 across the descriptor/policy/miniscript namespaces to be somewhat confusing and kind of unfortunate, made me jump through a bunch of hoops when implementing this in my minsc runtime. but I realize that ship has long sailed 🙂)}

[shesek]

I guess that one option is to just drop Descriptor::Pkh entirely and treat it as a case of Descriptor::Bare. Not sure if that's really desirable though, probably breaks the existing API too much?

[apoelstra]

I think we had this at some point in the past. Unfortunately it wouldn't fix this issue -- no matter what, if you type bare(X) where X is the same as one of the privileged top-level fragments, then you'll lose the bare when round-tripping to a string.

Personally I think a more sensible API direction would be to make the Bare descriptor be a sort of second-class citizen. In the new validation params stack we could provide an option to refuse to parse it, for example.