Add the UTXO_P2TR_BIP86 in preparation to add BIP86 wallet functions such as newaddr, listaddr etc. We also add a new index in the database for BIP86 as this is using a completely different derivation path and hsm_secret.

We should now be able to get BIP86 Taproot addresses through lightning-cli! For now we're just adding taproot addresses.

In the case where we receive a taproot utxo we want to be able to tell if it was derived using a BIP32 seed or a BIP86 seed. Considering we will only be supporting BI86 type wallet addresses for mnemonics we can check if the out secret is 64 bytes long and if it is we can use our BIP86 for the withdrawal.

This commit is updating hsmtool and exposesecrets to use the new pattern for storing the secret, which is the secret_data and secret_len, to support both 64 byte and 32 byte seeds.

This commit fixes an issue where BIP86 addresses were not being
discovered during wallet recovery/rescan operations.

The root cause was that init_txfilter() only populated the transaction
filter with BIP32-derived keys, preventing lightningd from recognizing
BIP86 UTXOs during blockchain scans. Now both BIP32 and BIP86 derived
scripts are included in the filter when BIP86 derivation is enabled.

This ensures that wallets restored from BIP39 mnemonics can properly
discover and display previously funded BIP86 addresses without requiring
manual address generation first.

[ We also move the slightly-lost comment about libbacktrace so it is
  where we actually include <backtrace.h> --RR ]

We're removing --use-bip86-derivation. Since a mnemonic will now be the standard hsm_secret BIP86 base wallet addresses will also be the standard.

This simplifies the UTXO type system by removing the separate BIP86
enum value. P2TR addresses will now use unified derivation logic
based on the wallet's HSM secret type rather than having separate
enum values."

Add TLV field to hsmd_init_reply_v4 to communicate the HSM secret type
(mnemonic vs legacy) from HSM to lightningd. This allows lightningd to
automatically determine whether to use BIP86 or BIP32 derivation without
needing separate address types.

…IP32 approach

Simplify wallet address generation by using a unified approach where
the derivation method (BIP86 vs BIP32) is determined by the wallet's
HSM secret type rather than having separate address types.

…roach

Copy corpora, since it's the same code paths.

Thanks Claude!

Signed-off-by: Rusty Russell <[email protected]>

Changelog-Removed: Remove hsm_encryption files as they have now been replaced by hsm_secret

This schema change updates newaddr to remove bip86 which was previously added, since don't want to make unnecessary schema changes this is being removed.

The generated files for the exposesecret schema change are also being added

Introduces a generic utility function to replace the repeated pattern of
sodium_mlock() + tal_add_destructor()

Signed-off-by: Rusty Russell <[email protected]>

…_file_raw!

Signed-off-by: Rusty Russell <[email protected]>

Signed-off-by: Rusty Russell <[email protected]>

Instead of having a separate field to derive the bip86 base key, we return it in the hsmd init reply once we know that the hsm_secret is of mnemonic type