Failure to parse `pk(xprv.../*)` descriptor

[brunoerg]

See bitcoinfuzz/bitcoinfuzz#70.

The following descriptor pk(xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U/*) fails to be parsed due to "Public keys must be 64/66/130 characters in size"/"pubkey string should be 66 or 130 digits long, got: 113".

[apoelstra]

I believe that this is a gap in the definition for DescriptorPublicKey.

It may be that we want to reorganize the type to always have a derivation path (or maybe a vector of derivation paths or something).

The relevant spec is BIP 380 https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki#user-content-Key_Expressions

[brunoerg]

bitcoinfuzz/bitcoinfuzz#70 (comment)

cc @trevarj

[trevarj]

@brunoerg thanks for the reminder, forgot about this.

Quoted from the bitcoinfuzz issue:

I could hack this to work by adding a case to FromStr for DescriptorPublicKey that checks if it's a xprv key and then just derive the xpub, but I'm not sure if that's what @apoelstra has in mind.

I think someone might also expect parsing as a Descriptor (or even Descriptor<DescriptorXKey> to work, but they don't.

I will open up a draft PR so we don't lose my hacky fix.

[trevarj]

Hi @brunoerg, can you change the fuzz to use Descriptor<DescriptorPublicKey>::parse_descriptor() instead?

This is how we are going to mitigate the issue: #970 (comment)

[brunoerg]

Hi @brunoerg, can you change the fuzz to use Descriptor<DescriptorPublicKey>::parse_descriptor() instead?

This is how we are going to mitigate the issue: #970 (comment)

Sure, will do it.

[brunoerg]

Done in bitcoinfuzz/bitcoinfuzz#570

[apoelstra]

I'm going to leave this issue open since we are in violation of the key-expression spec by not supporting xprvs directly.

It may be that our DescriptorPublicKey type should actually be DescriptorKey and be an enum that might contain a public or a private key. This would be mildly annoying since we need to be more careful with our secret-data APIs than for normal APIs.