The Bitcoin Core wallet prevents mainnet Taproot descriptors from being imported pre activation (November 2021) as a safeguard. However, you can send mainnet Bitcoin to a Taproot (P2TR) address pre activation. Should the sendtoaddress Core RPC prevent you from sending mainnet Bitcoin to a P2TR address pre activation?

2 Answers 2


TL;DR: Wallets SHOULD allow sending to all bech32m addresses at this point, but wallets MUST NOT request P2TR outputs before the Taproot spending rules are enforced on the network¹.

The design of segwit anticipated the lengthy process that is the adoption of optional features. Case in point, segwit activated in August 2017, yet Blockchain.com, a wallet service provider facilitating a significant portion of all Bitcoin transactions, added sending support for bech32 addresses only in June 2021.

Segwit made the concession of the forward-compatible P2SH-wrapped addresses to make the advantages of the segwit output types quickly available to the ecosystem (e.g. for Lightning), and laid the groundwork for a smoother rollout of later native segwit output types: BIP173 specified that all future versions of native segwit outputs should be considered valid addresses by default. Bech32 implementations complying with BIP173 would therefore have had out-of-the-box sending support for all future native segwit output types. (The same approach was adopted for bech32m.)

Allowing sending to seemingly undefined addresses is safe under the following two premises.

  1. Specifying under which conditions a receiver accepts a payment is the receiver's job and prerogative. Between the invoice and the on-chain record a sender can prove that they complied with the receiver's instructions. An honest receiver will only provide an address that they can safely spend funds from. In the most charitable interpretation, a sender wallet doing a sanity check on the receiver's instructions would at best amount to a courtesy.
  2. An attacker has no benefit from providing an address that sends funds to an anyone-can-spend output versus claiming the funds for themselves, and if for some inexplicable reason they just wanted to make funds unspendable, they could simply create an address they don't possess the private key for.

In exchange for making the natural concession to rely on the receiver to choose a reasonable output type, the ecosystem gains the major boon of making the rollout of all foreseeable new output types instant.

¹Obviously, this should be assessed per network and it's perfectly reasonable to generate P2TR addresses on testing networks especially where Taproot's rules are already enforced, such as e.g. Signet.


For a sender to send to a P2TR address pre activation they must have received that P2TR address from the receiver and so it would be an indirect safeguard to protect the receiver having given out P2TR addresses prematurely. The receiver's funds being vulnerable to being stolen pre activation isn't the sender's direct concern.

There are already safeguards in Bitcoin Core pre activation such as no generation of mainnet Taproot addresses (it is generally recommended that any wallet should prevent mainnet Taproot addresses from being generated pre activation) and mainnet Taproot spends not being relayed (no such restrictions are imposed on regtest, signet where Taproot has already activated). This restriction on the sendtoaddress RPC would make it conditional on the current block height or alternatively the user would need to upgrade to the latest version to be able to send to a P2TR address post activation. As it is, a wallet does not need to be Taproot upgraded or Taproot aware to be able to send to a P2TR address.

The introduction of SegWit v0 addresses had this problem where very few people were using SegWit v0 wallets post SegWit activation because no wallets could pay to such addresses. In addition, services had no incentive to upgrade to SegWit v0 because there was no demand to be paid to such addresses.

Thanks to various individuals who answered this on IRC and Murch for his suggested edit. Any mistakes are my own.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.