[feature]: optionally generate asset group key without internal key tweak during minting

[ffranr]

The asset group key is derived by applying two distinct tweaks to a raw public key: the Internal Key Tweak (known as the "single tweak" in code) and the Tapscript Root Tweak. The Internal Key Tweak ensures the asset group key is unique to the genesis asset ID, while the Tapscript Root Tweak binds the key to the conditions encoded in the Taproot script tree. The resulting key allows for securely identifying and reissuing assets within a group.

Problem: Asset Group PSBT External Signing

Applying the Internal Key Tweak to the raw signing public key prevents an external PSBT hardware wallet signer from signing the PSBT, which is necessary for generating the asset group witness and for validation within the tap VM. This limitation arises because the PSBT signer cannot recover the raw signing public key from the tweaked internal key, as the Internal Key Tweak obscures the original public key.

In addition, the PSBT format, along with most hardware wallets, currently lacks support for specifying the Internal Key Tweak. Such support would be necessary to identify the underlying raw signing key and correctly derive the tweaked Taproot internal key.

Solution Part 1: Adjust Asset Group Key Generation Process

The proposed solution introduces a flag to allow skipping the Internal Key Tweak step when generating an asset group key. The implementation will proceed as follows:

1. Add a flag to the MintAsset RPC endpoint to specify whether the Internal Key Tweak step should be skipped. This flag defaults to false.
2. Populate the flag in the tapgarden.Seedling struct to carry the configuration through the minting process.
3. Pass the flag to the GroupKeyRequest type struct to ensure the choice persists through the relevant logic.
4. Update the asset.GroupPubKey function to respect the flag, bypassing the Internal Key Tweak step if the flag is set.

Proposed flag name: SkipInternalKeyTweak.

Solution Part 2: Adjust GroupKeyReveal Verification Process

To ensure backward compatibility while supporting asset group keys generated without the Internal Key Tweak, the GroupKeyReveal verification process needs to be adjusted as follows:

1. Attempt to derive the asset group key by skipping the Internal Key Tweak. Apply only the second tweak (Tapscript Root Tweak) to the raw signing key.
2. If the derived key matches the asset group key, the verification is complete.
3. If the derived key does not match, apply the Internal Key Tweak as usual, followed by the second tweak, and check against the asset group key.
4. If neither derivation matches, the verification fails.

This modification ensures compatibility with both tweaked and untweaked asset group keys while maintaining existing functionality.

[jharveyb]

Some risks here:

• If the single tweak is dropped, you would be able to derive the same tweaked group key across asset group anchors, which is currently impossible. This would break other assumptions around what an asset group means, e.x. "All assets of a group are the same type, Normal or Collectible."

I'm sure there are other risks wrt. what aspect this loosening would affect.

It looks like there is a proposed BIP that exactly addresses this need:

https://github.com/bitcoin/bips/blob/master/bip-0372.mediawiki

But I'm not sure how widely it has been adopted.

As an alternative, we could consider a new means of committing to the group anchor asset ID. We could borrow the unspendable leaf pattern we use for the Tap commitment root to commit to the anchor asset ID, alongside the Group Key Tapscript Root. If there is no Group Key Tapscript Root, we can re-use the BIP-86 behavior of committing to the pubkey of the internal key as an unspendable script. Concretely:

• Remove the single tweak; the only tweak used would be derived from a tapscript tree root.

• The tapscript tree is now constructed as follows:

• • Create an unspendable TapLeaf from the group anchor asset ID (group anchor TapLeaf).
• • If no tapscripts are present, create another unspendable TapLeaf from bytes(internal_pub_key). Create the final tapscript tree with these two leaves.
• • Otherwise, tapscripts are present. Create a tapscript tree from these leaves, and use that root as a sibling for the group anchor TapLeaf. Create the final tapscript tree.

With this pattern (or similar), we can remove the problematic single tweak without removing the commitment to the group anchor asset ID. This should improve the compatibility with hardware signers without meaningfully changing the assumptions around group keys.

@Roasbeef

[jharveyb]

Not sure if we can pass all of the correct tweaks with the existing PSBT Taproot fields:

https://github.com/bitcoin/bips/blob/master/bip-0371.mediawiki