Key path spend disabling in miniTapScript

[rafaelpac]

Hi!
I was trying to play with Krux and Nunchuck-Android wallet.
I came across a situation that I described on an issue in their repo.
It might be a problem on Krux, or on Nunchuck, or I am just being stupid and trying to use the wallets off spec.

I will paste below what I opened there:

Hi, I came across an issue with the Nunchuck Android wallet (version 2.2.0 311, from Google Play), but I am not sure if it is really an issue in this codebase, another codebase (Krux) or just me being reckless and trying to use the wallet off spec.
But maybe it is indeed an issue here, sorry if not.

In this blog post you say that Taproot Miniscript is supported for Coldcard, Ledger and Specter DIY. I beleive this is outdated (Jade is also already supported, right?). Actually, as per my reckless poking around, Jade was the only option that let me add a Taproot Miniscript key.

But I dont have a Jade. I am using a Krux wallet.

So, here is what I've done: on Krux, I create a seed and configure it for a [mainnet, miniscript, taproot, m/48h/0h/0h/2h] wallet descriptor. Export xpub.

On Nunchuck, import key (the xpub above). I did it first as a Generic Airgap type of key, more on that later.
Then, create wallet: miniscript -> taproot -> select any kind of miniscript -> add key.
Here it says, greyed out, "Key path disabled".
To add keys, the Krux key imported will also be grayed out: "Keys not yet supporting Taproot".

I went back to the key import. I tried all the ones that would allow me to import an xpub from QR: Coldcard, Jade, SeedSigner, Keystone, Foundation.
Of all of these, the only option that would make the key available for use on a miniTapScript was the Jade.
I am really lost in this Kotlin thing, can't understant it, so I couldn't find where in the code this would be set.

Well, I went ahead with the "trans Jade" (actually a Krux miniTapScript xpub) and created a wallet. Then, export Descriptor. And try to import it on the Krux.

The Krux gives me "Internal key not provably unspendable".
I can see how they check for it: Krux tapkeypath NUMS (Nothing Up My Sleeve)

I also exported the descriptor from Nunchuck as text and base58-decoded the first xpub (the key path). It does use the BIP-341 NUMS 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0

So, in summary, both Nunchuck and Krux are apparently doing it alright: disable the taproot key path with the BIP341 suggested NUMS.
But, for some reason, they are disagreeing somewhere. I can see how Krux did it (hash the other keys in series and use that as chaincode for the xpub). But I can't understant Kotlin and I don't know how Nunchuck did it.

Sorry to maybe bother with my ignorance, but maybe you can find the origin of this. Thank you for your attention to this matter!

[odudex]

You pretty much figured out and did a precise diagnostic.
Nunchuk will allow Taproot with a "brand based" check, so you have to lie you're using a Jade.
On provably unspendable keys, we built our check based on Liana standard, and we didn't adapt it yet to Nunchuk's. I'll take a look at that early next year.

[rafaelpac]

Some reference for this: bitcoin/bips#1746
It looks like that Ledger and Coldcard don't care about the key path chaincode while checking a taproot miniscript descriptor.
The only check performed by these signers is the NUMS pubkey.
Coldcard seems to create descriptors with random chaincodes (that is not a problem for Krux, since it only imports descriptors): https://github.com/Coldcard/firmware/blob/new_edge/docs/taproot.md#provably-unspendable-internal-key
I don't know how Nunchuck does it, but at least it is not a fixed chaincode (might be random or not, but I think it doesn't really matter for the signer).
Other nice discussion about it: https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304

[odudex]

Yes, the best is probably just flex and remove the chain code restriction.