Why Don’t More Bitcoin Wallets Support Multiple Script Types?

[Sowat]

Despite the fact that the wallets are derived from the same seed phrase, most bitcoin wallets demand their users to generate or import other wallets for storing another type of address. For example, a user will be forced to run three distinct instances of the wallet for the following address types: legacy, Seg Wit (bech32) and Taproot (bech32m). From the usability point of view, it looks like a useless thing. It should be possible to use one seed for deriving multiple scripts, and the user should be capable of tracking the balances, transferring UTXO and making transactions from one wallet.

It can also be observed that there is a specific interesting feature related to the privacy. If the same script type is used by the wallet, then the change addresses for this wallet are predictable. Combining change types for a specific recipient can make them more difficult to guess and it reduces waste of information.Multiple script types are already supported by a handful of Bitcoin wallets. It is not a new technology. The question is, why doesn't this catch on in current wallet software?

What do you say? Developers and those who have been in the know with Bitcoin for a long time, what's stopping you from doing this?

[Mia Chloe]

~

I think the main issue is actually not technical difficulty but compatibility and UX. even if a single seed can actually derive addresses across legacy SegWit and Taproot, wallets still need clear derivation paths and stuffs like gap limit handling for each script type.

So literally supporting everything in one wallet can also make recovery less predictable across different wallet software. Because of that some developers just choose separate wallets because it is simpler that is part of the reasons why some wallet still don't support some of them.

[Charles-Tim]

No need of having change address anytime you are sending coins, just send the remaining coin (which is the change) to another script type address while sending bitcoin in a way no change will remain.

Wallet developers may not give you all that you need, but there are some ways you can go about it.

Even if some wallets have the feature, some people will lack privacy if they do not know much about how to have privacy with coin control and other necessary information needed.

[Forsyth Jones]

~

I think the main issue is actually not technical difficulty but compatibility and UX. even if a single seed can actually derive addresses across legacy SegWit and Taproot, wallets still need clear derivation paths and stuffs like gap limit handling for each script type.

So literally supporting everything in one wallet can also make recovery less predictable across different wallet software. Because of that some developers just choose separate wallets because it is simpler that is part of the reasons why some wallet still don't support some of them.

I don't see a problem with a wallet unifying address types into a single wallet (same wallet.dat or electrum default_wallet and etc) the derivation paths are already defined, each in its own BIP:

BIP44 handles legacy addresses, which occupy the hdkeypath=m/44h/0h/0h
BIP49 nested segwit addresses hdkeypath=m/49h/0h/0h
BIP84 native segwit bc1q hdkeypath=m/84h/0h/0h
BIP86 bech32m taproot bc1qp hdkeypath=m/86h/0h/0h

Basically, all wallets that support these address types use the derivation path above, which is the standard. In the past, some wallets used different derivation paths based on BIP32, such as m/0h or m/0h/0, but today almost all known wallets use the derivation paths above, from BIP44 to BIP86.

Regarding the gap limit, Electrum, for instance, scans 20 initial addresses and then another 20 and so on... while Bitcoin Core's default gap limit is 999 (or 1000 if we count from index=0). Bitcoin Core already has the features the OP mentioned, as well as Coinomi, Mycelium, and Wasabi (native segwit and segwit Taproot). These wallets mix scripts, unify balances and work very well that way. I think most of them have the privacy guard feature.

I think most wallets don't bother implementing this because there isn't enough demand.

Edit: I for example, just checked the size of a Bitcoin Core wallet.dat file with 16 descriptors 08 descriptors in total (2 for each script type, 1 for receive and another for change), and the file is only 28.0 KiB. That means each descriptor in Bitcoin Core by default generates a batch of 1000 addresses for each script (this can be changed).

Correction: it's only 08 descriptors   there are only 16 desc if the user has already created a wallet.dat without encrypting it beforehand. Bitcoin Core generates 08 more descriptors and sets them as active after the user encrypts wallet.dat. This is a security measure.

28.0 KiB is even smaller than a low-resolution photo, practically an insignificant amount of disk space compared to downloading a full or pruned node.

[Sowat]

I don't see a problem with a wallet unifying address types into a single wallet (same wallet.dat or electrum default_wallet and etc) the derivation paths are already defined, each in its own BIP:

BIP44 handles legacy addresses, which occupy the hdkeypath=m/44h/0h/0h
BIP49 nested segwit addresses hdkeypath=m/49h/0h/0h
BIP84 native segwit bc1q hdkeypath=m/84h/0h/0h
BIP86 bech32m taproot bc1qp hdkeypath=m/86h/0h/0h

Basically, all wallets that support these address types use the derivation path above, which is the standard. In the past, some wallets used different derivation paths based on BIP32, such as m/0h or m/0h/0, but today almost all known wallets use the derivation paths above, from BIP44 to BIP86.

Regarding the gap limit, Electrum, for instance, scans 20 initial addresses and then another 20 and so on... while Bitcoin Core's default gap limit is 999 (or 1000 if we count from index=0). Bitcoin Core already has the features the OP mentioned, as well as Coinomi, Mycelium, and Wasabi (native segwit and segwit Taproot). These wallets mix scripts, unify balances and work very well that way. I think most of them have the privacy guard feature.

I think most wallets don't bother implementing this because there isn't enough demand.

Edit: I for example, just checked the size of a Bitcoin Core wallet.dat file with 16 descriptors 08 descriptors in total (2 for each script type, 1 for receive and another for change), and the file is only 28.0 KiB. That means each descriptor in Bitcoin Core by default generates a batch of 1000 addresses for each script (this can be changed).

Correction: it's only 08 descriptors   there are only 16 desc if the user has already created a wallet.dat without encrypting it beforehand. Bitcoin Core generates 08 more descriptors and sets them as active after the user encrypts wallet.dat. This is a security measure.

28.0 KiB is even smaller than a low-resolution photo, practically an insignificant amount of disk space compared to downloading a full or pruned node.

I buy into your one. As there are well specified derivation path for BIP44, BIP49, BIP84 and BIP86 scripts, a wallet can manage multiple script types with one wallet architecture. The different script types will be kept logically isolated from one another and still potentially operated with one wallet. Your Bitcoin Core example is most compelling because you have shown that mixed script UTXOs, balanced sums, signing, backup + restore, and fee calculation work without completely separate wallets. The wallet can determine script type and derivation path for each descriptor and treat it correctly.

I believe that no issues with the problem of gap limit. Electrum and Bitcoin Core searching for addresses is incompatible, but it demonstrates the ability to discover and process automatically addresses and remove the requirement for independent handling by the user each type of script. The wallet size worries look pretty reasonable as well. While there are a few descriptors in wallet and even the duration of big ranges of addresses, the extra volume of reminiscence required is not an enormous job throughout the general size of Bitcoin node. So it seems that the only thing that is bringing us back is only implementation priority and user demand.