Please unbreak single-key wallets (and potentially remove internal/external distinction entirely)

[stevenroose]

In alpha.9 or something, I could pass None for the internal descriptor. Now it is no longer an Option, so I passed in the same descriptor, but we get an error that they can't be the same.

We have a wallet that is a single key, simple tr(<pubkey>) descriptor where internal and external addresses are identical. This used to work perfectly before.

We are hitting this message: write!(f, "External and internal descriptors are the same")

[storopoli]

This was discussed in #1383

[stevenroose]

Hmm, from reading the convo, it's not very clear that the explicit decision was made to no longer support single-key wallets. What is the difficulty in doing so? I don't fully understand what this change makes internal development easier.

I would like to strongly request to bring back support for single-key wallets. Also, the internal/external distinction is kinda stupid anyway, I don't see a good reason to keep this structure altogether. I think if BDK wants to take a progressive stance, it should do away with the dual descriptors entirely and just have a single descriptor. (AFAIK the difference originated in wallets not being able to remember which addresses were already given out so they would accidentally use an address they gave to someone for change. But since BDK, and more modern wallets for that matter, never allow re-handing out an address, having both is no longer needed. When you need a change address, you can just pull a new address from the key pool.)

[stevenroose]

EDIT: It seems that another motivation for the distinction is to enhance privacy for users that use Electrum-like servers. They could avoid informing the server about their internal addresses. Ever since we have compact block filters, Electrum-like setups are less and less needed and we should definitely think about making progress away from this model and not doubling down on it, IMO.

[notmandatory]

Unfortunately many/most of our users are still using electrum and/or esplora servers so I think this privacy concern still exists. I can see us removing this restriction in the future once CBF is more common, but for now the decision was to be more opinionated with the Wallet apis and to support the more common uses.

If you want to use BDK for less common scenarios you can still construct a custom wallet using the bdk_chain crate, which we have examples for.

[stevenroose]

You are deciding to provide a worse experience for users that have better wallet practices? All wallets that use bitcoind, cbf, their own personal electrum server or anything else that is not a public blockchain index, are now suffering that they need to deal with two different descriptors, potentially write these down, etc etc, all because a lot of other users do use Electrum?

Also, entirely dropping support for single-key wallets is also a very big feature cut IMO that should be discussed independently of the int/ext discussion.

[notmandatory]

Maybe I don't understand your use case for TR single key wallets, would these always produce the same SPK? are they needed for LN taproot channels or some other type of TR user?

[notmandatory]

I put this on the discussion tab for our alpha milestone to get feed back from others on the team on if we really need to revert #1390.

[ValuedMammal]

It shouldn't be too difficult to build in support for single descriptor wallets. Long term we might consider doing away with KeychainKind enum and supporting wallets with one or more keychains.

[notmandatory]

@stevenroose have you taken a look at the example_bitcoind_rpc_polling cli wallet ? it's an example that is built on just the bdk_chain crate and doesn't use the bdk_wallet at all. This would be the best way to use BDK for a custom on-chain app with a single keychain or any other custom behavior. The example isn't fully fleshed out but we'll be doing that once we get the first beta release out.