<h2>Background</h2>
<p>P2TR addresses will be encoded using <em>Bech32</em>, although likely an amended version. In anticipation of Taproot getting merged, some proponents tested the behavior of various wallets and services regarding segwit v1 outputs. <a href="https://en.bitcoin.it/wiki/BIP_0173" rel="noreferrer">BIP173</a> prescribes that known restrictions should be enforced for Bech32 addresses, but that &quot;implementations MUST allow the use of any version&quot;. The tests found that multiple wallets and services did not adhere to the spec, but rather either failed to create segwit-v1 outputs, or worse, silently downgraded them to segwit-v0 outputs, using the same output script but malleating the segwit version and thereby burning the funds.</p>
<p>Last year, it was also discovered that Bech32 is subject to a length extension mutability. Addresses with a specific ending can be <a href="https://bitcoin.stackexchange.com/q/91602/5406">extended</a> by inserting specific characters (or removing them if they appear in specific positions). This is largely inconsequential for native segwit addresses due to their restriction to either 42 or 62 characters.</p>
<p>A <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018236.html" rel="noreferrer">recent proposal</a> aims to fix both issues by amending the checksum calculation for Bech32. Using this amended format for upcoming segwit output verisons would protect funds from being burned as downgraded outputs would no longer comply with segwit-v0 checksum requirements, and at the same time remedy the length extension mutability for segwit-v1–v16.</p>
<h2>Paying to segwit v1 addresses</h2>
<p>The segwit spec explicitly permitted creation of all versions of segwit outputs. Therefore, it was expected that all segwit-enabled wallets would be able to create P2TR outputs out of the box.
According to the mentioned tests, many wallets and services did not comply with the spec, but would require updates to support sending to P2TR. Under the proposed change, wallets would have to additionally update the checksum constant for segwit-v1–v16 bech32 addresses.</p>
<h2>Spending from P2TR outputs</h2>
<p>The Taproot BIPs prescribe a new script version (<a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="noreferrer">Tapscript</a>), <a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki" rel="noreferrer">Schnorr signatures</a>, and the <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="noreferrer">Taproot output format</a>, so spending from P2TR outputs will require more implementation work in the first place, especially to make use of advanced features such as script path spends or using aggregated keys in the key path.</p>

CC BY-SA 4.0
2020-12-01T13:22:30.280Z
2020-12-29T17:41:57.107Z
2020-12-29T17:41:57.107Z
Murch
<p>Dawid Ciężarkiewicz <a href="https://twitter.com/dpc_pw/status/1333679281088589824" rel="noreferrer">asked</a> on Twitter:</p>
<blockquote>
<p>Hey #bitcoin ers. I'm trying to figure out why taproot needs a new
address format, as I missed it. If you have a good link or something -
please share. I thought that &quot;A Taproot output is a native SegWit
output with version number 1 (...)&quot; means that bech32 will do.</p>
</blockquote>
<p>and I'm asking the question here to provide better visibility to the question and answer.</p>

<segregated-witness><bech32-address><taproot>
Why does Taproot require a new address format?
Murch
# Why does Taproot require a new address format?

(Asked by: username_0 on 2020-12-01)

Dawid Ciężarkiewicz [asked](https://twitter.com/dpc_pw/status/1333679281088589824) on Twitter:

> Hey #bitcoin ers. I'm trying to figure out why taproot needs a new
> address format, as I missed it. If you have a good link or something -
> please share. I thought that "A Taproot output is a native SegWit
> output with version number 1 (...)" means that bech32 will do.

and I'm asking the question here to provide better visibility to the question and answer.

**Tags:** segregated-witness, bech32-address, taproot


---

## 1 answers

### Answer by username_0 on 2020-12-01. Score: 15 | Accepted answer

## Background

P2TR addresses will be encoded using *Bech32*, although likely an amended version. In anticipation of Taproot getting merged, some proponents tested the behavior of various wallets and services regarding segwit v1 outputs. [BIP173](https://en.bitcoin.it/wiki/BIP_0173) prescribes that known restrictions should be enforced for Bech32 addresses, but that "implementations MUST allow the use of any version". The tests found that multiple wallets and services did not adhere to the spec, but rather either failed to create segwit-v1 outputs, or worse, silently downgraded them to segwit-v0 outputs, using the same output script but malleating the segwit version and thereby burning the funds.

Last year, it was also discovered that Bech32 is subject to a length extension mutability. Addresses with a specific ending can be [extended](https://bitcoin.stackexchange.com/q/91602/5406) by inserting specific characters (or removing them if they appear in specific positions). This is largely inconsequential for native segwit addresses due to their restriction to either 42 or 62 characters.

A [recent proposal](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-October/018236.html) aims to fix both issues by amending the checksum calculation for Bech32. Using this amended format for upcoming segwit output verisons would protect funds from being burned as downgraded outputs would no longer comply with segwit-v0 checksum requirements, and at the same time remedy the length extension mutability for segwit-v1–v16.

## Paying to segwit v1 addresses

The segwit spec explicitly permitted creation of all versions of segwit outputs. Therefore, it was expected that all segwit-enabled wallets would be able to create P2TR outputs out of the box.
According to the mentioned tests, many wallets and services did not comply with the spec, but would require updates to support sending to P2TR. Under the proposed change, wallets would have to additionally update the checksum constant for segwit-v1–v16 bech32 addresses.

## Spending from P2TR outputs

The Taproot BIPs prescribe a new script version ([Tapscript](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki)), [Schnorr signatures](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), and the [Taproot output format](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki), so spending from P2TR outputs will require more implementation work in the first place, especially to make use of advanced features such as script path spends or using aggregated keys in the key path.


---

