7

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?

1
  • 4
    It's important to note that Taproot originally was going to use Bech32 addresses so, if every wallet had implemented them correctly, there would not be an upgrade issue. The Bech32 BIP states that wallets should still be able to send even if it does not know about the witness version. This is now slightly complicated by the use of bech32m for witness v1+. – Andrew Chow Jun 1 at 0:32
4

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.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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