Dawid Ciężarkiewicz asked 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.
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 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 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 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.
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.
The Taproot BIPs prescribe a new script version (Tapscript), Schnorr signatures, and the Taproot output format, 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.
