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.

[pooya87]

Because implementing such a feature that is only used by a minority of users is difficult and adds more complexity to the wallet software while the focus is on keeping things simple for majority of users. Not to mention it makes recovery from mnemonic so much more difficult. The users would have to manually reproduce their steps to recover the same exact wallet from their mnemonic or the software would have to scan all derivation paths and address types which would add more complexity and computation and consumes more traffic.

On top of that such a major change in the wallet layer is not top priority for the developers. Usually they are working on other stuff that has more demand. For example the Electrum guys have been actively developing LN related code among other things. There usually is not enough time left to dedicate for developing a feature that doesn't have that much demand.

[nc50lc]

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?

Best answers should be straight out of the developers' posts, agree?

E.g.: Electrum that doesn't support multi-script type wallets (yet).
I'll link some for you:

• github.com/spesmilo/electrum/issues/4345#issuecomment-386913446
  This is quite old, so their stance might have changed, but it suggests that it's to keep backwards-compatibility of their proprietary seed phrase and derivation path implementation.
• github.com/spesmilo/electrum/issues/3283
  This is a bit of a history, they were discussing on how to support P2WPKH at that time.
  Now, P2WPKH is implemented but P2PKH is deprecated instead of combining the two in the same wallet file most probably because of the above.

But despite of that, there's a plan to introduce an "Advance Wallet" feature that can support multi-scripts: github.com/spesmilo/electrum/issues/6016
It's still waiting for output script descriptor to be implemented in Electrum though.

[Forsyth Jones]

Because implementing such a feature that is only used by a minority of users is difficult and adds more complexity to the wallet software while the focus is on keeping things simple for majority of users. Not to mention it makes recovery from mnemonic so much more difficult. The users would have to manually reproduce their steps to recover the same exact wallet from their mnemonic or the software would have to scan all derivation paths and address types which would add more complexity and computation and consumes more traffic.

On top of that such a major change in the wallet layer is not top priority for the developers. Usually they are working on other stuff that has more demand. For example the Electrum guys have been actively developing LN related code among other things. There usually is not enough time left to dedicate for developing a feature that doesn't have that much demand.

Ok, it might be relatively difficult, but what’s the harm in trying? No one has tried yet on wallets like electrum, so how did you come to such a conclusion? And what if I told you that Bitcoin Core and other wallets like Coinomi, Mycelium have this same type of behavior?

This is already on the Electrum wallet backlog on #6016 I think I’ve already had this discussion with you in my thread before.

About LN: can you point me to anyone using the Lightning Network on Electrum? To this day, I haven't seen anyone using it, I tried it on testnet and ended up losing my balance on 2020, and what is the need for LN now when fee rates range from 0.1 sat/vB to 5 sat/vB? Don't get me wrong, I used to be a huge LN enthusiast, but it never advances, there are too many bottlenecks, and it’s extremely hard to understand within Electrum.

I used LN yesterday to make a payment, and I did it through Phoenix, literally all you have to do is add some sats, open a channel in 02 clicks and voilà, and keep topping it up, without worrying about forced closures.

I consider Taproot and Silent Payments to be much more important than LN in Electrum.

Most Electrum users use Electrum  because it’s a great option for cold storage, long-term fund storage, or even to use integrated with hardware wallets, I think it’s a waste of time to bother with LN on Electrum when there are other wallets that handle LN much better than Electrum does...

[pooya87]

Ok, it might be relatively difficult, but what’s the harm in trying? No one has tried yet on wallets like electrum, so how did you come to such a conclusion? And what if I told you that Bitcoin Core and other wallets like Coinomi, Mycelium have this same type of behavior?

This is already on the Electrum wallet backlog on #6016 I think I’ve already had this discussion with you in my thread before.

That's right. And there is no harm in it, in fact this could be a useful feature for advanced users. But it's all about priorities and the priorities each developer has depends on the devs and their users. I'd say in Electrum the top-est priority should be adding Taproot support (to create a Taproot wallet and spend from it) but even though it is on their list, but it is near the bottom.

About LN: can you point me to anyone using the Lightning Network on Electrum? To this day, I haven't seen anyone using it,

I've never used it either
But that's the thing, it's the devs' priority. Why these priorities? Only they can answer that.

Let me give you an example... I don't call myself a developer but I have some stuff on github. For the past 2 years a lot of users have been requesting a certain features (like bookmark/highlight option) and I haven't added it yet because it is not a top priority for me. For starters I have no idea how to implement it without having to rewrite/refactor major parts of the code and possibly breaking stuff up. And also I have had other priorities to add with the very little time I have to dedicate to writing code for free! Priorities like improving the database, fixing UI bugs where things are messed up in RTL mode, working on separating the core so that we make it run on other platforms (like Android), etc.

[nc50lc]

-snip- and it’s extremely hard to understand within Electrum.

That's the price of full self-custody,
Electrum's LN feature is actually a lightning node and not just an interface like other wallets where the backend manages the channels for you.
They can still call theirs "self-custodial" since the keys are still controlled by the user, but it's like giving them the steering wheel when it comes with managing your lightning wallet.
I'd say it's a compromise between convenience and full control.

To this day, I haven't seen anyone using it

Personally, I've used it almost daily when it's the hot topic, I've had a long LN transaction history back from 2021~2025.
But lately when the on-chain fee is almost comparable to LN's fee, I closed my channels (sometime last year) since I don't see any use-case lately.
Perhaps sometime in the future, I'll see a compelling reasons on using it.

Some old transactions (scrolled-down history tab):

Fast forward to 2025 (another wallet, last channel-close txn marked):