Make bech32m the default for RPC, opt-in for GUI

[Sjors]

RPC
This makes bech32m the default whenever possible. For legacy wallets the default remains bech32. Same for descriptor wallets without an active Taproot descriptor.

GUI
A new wallet setting allows users to opt-in to Taproot. If they opt in, the GUI bech32 checkbox now produces either bech32 or bech32m depending on the wallet. This avoids having to explain the difference.

Considerations
This lets users and developers experiment with taproot wallets. When merged before #22364, the user will have to manually import a taproot descriptor. After that PR, taproot descriptors will be present for all new wallets.

It is better to stick to bech32 addresses for the time being, because:

1. It is expected that it will take a while for enough wallets and exchanges to correctly handle sending to bech32m addresses
2. Taproot savings for a single signature wallet are not huge
3. Explaining the difference between bech32 and bech32m is not great UX

But we don't want to prevent users and developers who do understand the difference to use Taproot. Without this PR they can only do this via the RPC (getnewaddress some_label bech32m). With this PR it's a simple checkbox.

Changing the RPC default to bech32m seems acceptable to me, since those users will have a better understanding of the wallet. Though I can see the case against it because it might be a breaking change, e.g. if someone has an automated setup that creates new wallets (existing wallets currently don't auto upgrade to taproot, so their behavior is not changed).

Suggested testing

• call getnewaddress without type and getnewaddress Test bech32 / bech32m
• create a receive address in the GUI with and without the bech32 checkbox

1. Legacy wallet
2. Default descriptor wallet (current does not have taproot descriptor)
3. Wallet with taproot descriptor:
   • build wallet: Make a tr() descriptor by default #22364
   • create new descriptor wallet
   • build this PR again

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #23308 (Update basic multisig test/docs to use multipath descriptor by mjdietzx)
• #22928 (refactor: Remove gArgs from wallet.h and wallet.cpp (2) by kiminuo)
• #22838 (descriptors: Be able to specify change and receiving in a single descriptor string by achow101)
• #22805 (refactor: use CWallet const shared pointers in dump{privkey,wallet} by theStack)
• #22787 (refactor: actual immutable pointing by kallewoof)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[michaelfolkson]

My understanding from discussion at they July 30th Core wallet meeting is that this will only be merged once the (super)majority of the ecosystem is able to make payments to bech32m addresses. So definitely post Taproot activation but uncertain at this stage when exactly.

Assuming I've understood above, Concept ACK. Thanks for the instructions for testing in the PR description, will do this testing at a later date.

[Sjors]

@michaelfolkson note that this doesn't do anything unless there's actually a taproot descriptor in the wallet, which this PR doesn't add.

[ghost]

tACK 2c2a8c0

https://bitcoin.stackexchange.com/a/108013/

[ghost]

Not sure why I don't see QR in bitcoin-qt

[Sjors]

Rebased.

My understanding from discussion at they July 30th Core wallet meeting is that this will only be merged once the (super)majority of the ecosystem is able to make payments to bech32m addresses.

I added a note in the PR description. I tend to agree it's preferable to wait a little bit until more wallets and services support sending to bech32m, otherwise we have to add another checkbox for bech32 fallback and explain all that.

[schildbach]

I wonder why this isn't already merged for Testnet and Signet (not Mainnet), both of which have Taproot activated already. It would make Taproot testing much easier.

[ghost]

reACK 9ca663e

[sipa]

@schildbach I don't think we can merge this until there is wide support for sending to bech32m in commonly deployed clients/services, which will probably take a while after activation even.

[Sjors]

I'm open to the idea of enabling this behavior on signet (and testnet) and turning it off on mainnet until a later release.

[Sjors]

I added a GUI settings checkbox to enable "taproot" (maybe needs rewording). See updated PR description.

[Rspigler]

Use Taproot -> "Generate taproot addresses for wallets that support it..." Instead, could the new GUI option only be shown to users who have updated to taproot capable wallets? Then once clicking 'Use Taproot', the GUI bech32 checkbox should auto-select and produce bech32m addresses.

[Sjors]

Do you mean moving it from the wallet Settings view to the Receive view? (and then only showing it for taproot capable wallets)

[Rspigler]

I didn't, but I believe that's a better idea

[DrahtBot]

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

[Sjors]

Closing this in favor of a GUI-only PR: bitcoin-core/gui#459