Support for P2WSH-wrapped P2TR addresses

Question

Given that Taproot addresses use a new SegWit version and a new address encoding (bech32m), it's reasonable to expect a transition from the ecosystem to this new address version similar to what we saw for the P2PKH/P2SH -> P2WPKH/P2WSH transition. It wouldn't be strange if we see at the very least a multi-month transition period, where some wallets can generate Taproot addresses, but many services like exchanges don't support making withdrawals to these new addresses.

Following that line of thinking, the transition to Taproot could be much smoother for wallets and end-users if we had a strategy similar to what the P2SH-wrapped outputs did for SegWit.

In BIP341, there's a security argument for why P2SH-wrapped outputs are not supported: since they use a 160-bit hash, they only provide 80 bits of collision resistance, which is too low. However, after 3.5 years of transition, most of the industry already supports withdrawals to P2WSH addresses. P2WSH outputs use a 256-bit hash, which provides the same 128 bits of collision resistance as the top-level P2TR outputs.

Is there any other reason for not supporting P2WSH-wrapped P2TR outputs?

Answer 1

In addition to the rationale given in BIP 341, I know of two arguments for not supporting P2SH-wrapped taproot outputs:

1. backwards-compatibility: P2SH-wrapped segwit outputs were included in BIP 141 as a way to allow unupgraded wallets to send outputs to upgraded segwit wallets[0]. Segwit activation happened around 4 years ago, and almost all wallets/services now allow sending to a bech32 (native segwit) address[1]. It was argued on the mailing list [2], [3] that by the time taproot activated, essentially the whole ecosystem would be able to send to bech32. bech32 was designed to be backwards-compatible, with future segwit versions using the same format. If all sending wallets can already send to native segwit v1 addresses, then there's no need for a P2SH-wrapped taproot compatibility format.

   The discovery of the bech32 malleability issue[4] and the development of bech32m[5] as a solution introduces a minor problem: wallets that are able to send to bech32 addresses will not be able to send to bech32m addresses without being upgraded. However, that upgrade is very straightforward and involves changing a single constant value. I expect that wallets should be able to roll out that change very quickly. At the time of writing, we have about 5 months until the Schnorr/Taproot softfork activation, which should be enough time for wallets and services to upgrade.

   This week's Bitcoin Optech newsletter will include a section on taproot sending support: https://bitcoinops.org/en/newsletters/2021/06/23/. (newsletter to be published on Wednesday).

2. Privacy and fungibility: "the major benefit of taproot is the better privacy and homogeneity afforded by Taproot, and supporting both P2SH-wrapped and non-wrapped SegWit v1 addresses simply increases the number of places that a user may be characterized and potentially identified" from ZmnSCPxj[6]. By making the output type uniform across all taproot spends, we increase fungibility for everyone.

Both of those arguments apply equally to a P2WSH-wrapped taproot as a P2SH-wrapped taproot.