On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for > > segwit > > v0 for compatibility reasons. Most wallets/exchanges/services now support > > sending > > to native segwit addresses (https://en.bitcoin.it/wiki/Bech32_adoption) and > > that > > will be even more true if Schnorr/Taproot activate in 12+ months time. > > > > Apologies for necroing an ancient thread, but I'm echoing my agreement with > > John here. > > We still have plenty of time to have ecosystem upgrade by the time taproot > > is likely to activate. > On the other hand, 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. I'm starting to lean towards not allowing P2SH wrapped Taproot as well. Given the progress bech32 adoption has made in the past year or so, I don't think adding P2SH support would result in many more software authors deciding to implement receive-to-taproot functionality. And without that advantage, having the option of supporting P2SH wrapping actually risks degrading the privacy goals it aims for (see ZmnSCPxj's argument above). My main intuition for keeping P2SH is that Segwit was really designed to support both, and I expect that disallowing P2SH would actually require (very slightly) more complex validation code. I don't think this is a sufficiently strong reason, especially as keeping P2SH support does increase the number of combinations software needs to test (both in consensus code and wallets). Cheers, -- Pieter _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
