<p>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.</p>
<p>There are already safeguards in Bitcoin Core pre activation such as no generation of mainnet Taproot addresses (it is generally recommended that <strong>any</strong> 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 <code>sendtoaddress</code> 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.</p>
<p>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.</p>
<p>Thanks to various individuals who answered this on IRC and Murch for his suggested edit. Any mistakes are my own.</p>

CC BY-SA 4.0
2021-06-22T17:51:36.297Z
2021-06-22T18:33:51.357Z
2021-06-22T18:33:51.357Z
Michael Folkson
<p><strong>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¹.</strong></p>
<hr />
<p>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.</p>
<p>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 <a href="https://bitcoinops.org/en/newsletters/2020/12/09/#bech32-addresses-for-taproot-and-beyond" rel="nofollow noreferrer">approach</a> was adopted for bech32m.)</p>
<p>Allowing sending to seemingly undefined addresses is safe under the following two premises.</p>
<ol>
<li>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.</li>
<li>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.</li>
</ol>
<p>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.</p>
<hr />
<p>¹<sub>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.</sub></p>

CC BY-SA 4.0
2021-06-23T16:42:06.157Z
2021-08-09T21:21:07.597Z
2021-08-09T21:21:07.597Z
Murch
<p>The Bitcoin Core wallet <a href="https://github.com/bitcoin/bitcoin/pull/22156" rel="noreferrer">prevents</a> mainnet Taproot descriptors from being imported pre activation (November 2021) as a safeguard. However, you can <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.1.md#taproot-soft-fork" rel="noreferrer">send</a> mainnet Bitcoin to a Taproot (P2TR) address pre activation. Should the <code>sendtoaddress</code> Core RPC prevent you from sending mainnet Bitcoin to a P2TR address pre activation?</p>

<wallet><taproot><output-script-descriptors><p2tr>
Should the Bitcoin Core wallet (or any wallet) prevent users from sending funds to a Taproot address pre activation?
Michael Folkson
# Should the Bitcoin Core wallet (or any wallet) prevent users from sending funds to a Taproot address pre activation?

(Asked by: username_0 on 2021-06-22)

The Bitcoin Core wallet [prevents](https://github.com/bitcoin/bitcoin/pull/22156) mainnet Taproot descriptors from being imported pre activation (November 2021) as a safeguard. However, you can [send](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.21.1.md#taproot-soft-fork) 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?

**Tags:** wallet, taproot, output-script-descriptors, p2tr


---

## 2 answers

### Answer by username_1 on 2021-06-23. Score: 9 | Accepted answer

**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](https://bitcoinops.org/en/newsletters/2020/12/09/#bech32-addresses-for-taproot-and-beyond) 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.


---

### Answer by username_0 on 2021-06-22. Score: 3

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 username_1 for his suggested edit. Any mistakes are my own.


---

