This will be possible in the upcoming Bitcoin Core 24.0 release, using RPCs like deriveaddresses
and importdescriptors
, which take as input specifications in the output descriptor language.
RPCs like createmultisig
, addmultisigaddress
, etc. only work in the older legacy wallets. Since version 0.21.0 a new type of wallets, called descriptor wallets, are supported by Bitcoin Core. These new wallets operate around the descriptor language, which precisely describes which addresses/outputs belong to the wallet.
In the descriptor language, for example one can write:
pkh(PUBKEY)
for a traditional P2PKH single-key output
sh(multi(2,PUBKEY1,PUBKEY2,PUBKEY3))
for P2SH-embedded 2-of-3 multisig over the provided keys.
sh(wsh(multi(1,PUBKEY1,PUBKEY2))
for P2SH-embedded P2WSH with 1-of-2 multisig in it.
In Bitcoin Core 22.0 support was added for tr()
in the descriptor language, though without multisig support (as the OP_CHECKMULTISIG
opcode which the multi()
descriptor language feature maps to does not exist in taproot scripts). In the upcoming Bitcoin Core 24.0 release, multi_a
is added which works like multi()
, but using a taproot-compatible script. It supports up to 999 keys. The way to use it would be:
tr(KI,multi_a(21,K1,K2,K3,K4,...,K210))
where KI
is the internal public key you want to use (which will need to be unspendable unless you want it to implement an (1-of-1)-or-(21-of-210) policy. BIP341 gives an example of an unspendable key, namely 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0
. K1
through K210
would be the public keys you want to use. They can be in 66-character hexadecimal notation (starting with 02 or 03), 64-character hexadecimal notation (for x-only pubkeys), or xpubs or xprvs. See the linked document above for more details.