public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Cc: John Newbery <john@johnnewbery.com>, Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 18 Sep 2019 14:21:56 -0700	[thread overview]
Message-ID: <CAPg+sBj4ADfX+VObboUoO7AJ4ONVREX4R1H6TmCnrJX2m0+65g@mail.gmail.com> (raw)
In-Reply-To: <A7FKsw5tH-KnsBfn-IVS2N1qJpjhh4ALsdO3nupkio_zeymKbmOFiNgpVVxkWXZIx6EqurdRHkmgVDtXKddLDhLBFq-3aebiaH8_BdNzDu0=@protonmail.com>

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


  reply	other threads:[~2019-09-18 21:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 17:57 [bitcoin-dev] Taproot proposal Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42   ` Sjors Provoost
2019-05-08  4:37     ` ZmnSCPxj
2019-05-08  5:16       ` ZmnSCPxj
2019-05-08 23:06     ` Pieter Wuille
2019-05-18 17:51       ` ZmnSCPxj
2019-05-08  3:44   ` ZmnSCPxj
2019-05-09 16:56     ` Johnson Lau
2019-05-10  5:38       ` ZmnSCPxj
2019-05-08  4:49   ` Anthony Towns
2019-05-08 13:10   ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23  2:06   ` Pieter Wuille
2019-05-23  2:32     ` Russell O'Connor
2019-05-22 14:14 ` John Newbery
2019-09-16 16:18   ` Greg Sanders
2019-09-17  4:09     ` ZmnSCPxj
2019-09-18 21:21       ` Pieter Wuille [this message]
2019-06-27  0:08 ` Russell O'Connor
2019-06-28  9:49   ` Anthony Towns
2019-06-28 11:16     ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPg+sBj4ADfX+VObboUoO7AJ4ONVREX4R1H6TmCnrJX2m0+65g@mail.gmail.com \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gsanders87@gmail.com \
    --cc=john@johnnewbery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox