1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C14BDD48
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Sep 2019 21:22:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com
[209.85.167.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53FEA81A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Sep 2019 21:22:08 +0000 (UTC)
Received: by mail-oi1-f179.google.com with SMTP id i16so918954oie.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 18 Sep 2019 14:22:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=wsehmlN0K63bGpMD+skG/dUdV10uU2JiD5XrVdKMSkA=;
b=tUxT+h9hLFz5qSFODPurrC90V0awoWml9gup3AHkeZHQdX+SC6wfeeFvS0rrAkVYkU
dHeLHZxAp+OAlMwibocKIDPhYC5h16PK+JN5SmgWKsUGW1jYcP81NcfbgLtIXS4xZ6R+
KZBKbdWm//hJeWvUfAofY0acM7SQF8ZZ0+wsF2fvIwcfRjyJ9sbxHdXHWtqoZrI/wn/9
tw/RuijxMdwZJaoqHySv/NPaRLCGi1R3GveZCobR7/P1HuIaWQ8LZGmDE2YNUlpB/lkP
nJwbjSPyv1GX7YTVrzaGumEY1W1luOpKkD6h3Xvr6deocZqBH8xe9p//gVGC1gil65wI
FkDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=wsehmlN0K63bGpMD+skG/dUdV10uU2JiD5XrVdKMSkA=;
b=fwd87RuAlfYocm1Lgafx0ZEfwQU490SdJQ58gmBgNqPaAmZFlaHLdCCIfKGhrx+PwA
5/rkzsJpBkC0K7TcJ5Z1xLtVRsLtZ4qPExHD6r95SFaBtw8ydO+xjxxUpxQfYFBdBirN
gK8xnLI2CzI9FmwlCj609sepclMNI6cZfBpaxmG5CFm/SF0kJNIOv0TAKgzZ3lkRtIOL
hubx1CVgJVDw8FDtCcXfqzIZ/AXDjALuIDHJbNxRtPQlVaj2xPToYr1m0BcQDWRWbvZ1
b6BwA66Xt5lhMi7aAM3fjgeae5gACRQ6UZuqmOR/IhlafwCREZDkbqC3S+3yQmlq3w28
NBjw==
X-Gm-Message-State: APjAAAUK/m6uEiVehOVt9FHyN/U1C9hG3IDN69lLs1KpIpi59mmZ9+Vk
BIClDMrdeAdT89uCuBC/171OM/Pkf6t6QsT0x8LnLLvP
X-Google-Smtp-Source: APXvYqxyDGQdpIQ+RH6aeBsg5+476GH4ZwzsFJl6tYhJSIUw3b/WG2xPpmcsehv5PFXmhnDd5RMPa57wi21cVu6mRZ0=
X-Received: by 2002:aca:cd12:: with SMTP id d18mr3587901oig.140.1568841727258;
Wed, 18 Sep 2019 14:22:07 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
<CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com>
<CAB3F3DvdUhZXO+hWZxdS64hO3gQGwGUURur5CA5Fp4hgn7g5EQ@mail.gmail.com>
<A7FKsw5tH-KnsBfn-IVS2N1qJpjhh4ALsdO3nupkio_zeymKbmOFiNgpVVxkWXZIx6EqurdRHkmgVDtXKddLDhLBFq-3aebiaH8_BdNzDu0=@protonmail.com>
In-Reply-To: <A7FKsw5tH-KnsBfn-IVS2N1qJpjhh4ALsdO3nupkio_zeymKbmOFiNgpVVxkWXZIx6EqurdRHkmgVDtXKddLDhLBFq-3aebiaH8_BdNzDu0=@protonmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Wed, 18 Sep 2019 14:21:56 -0700
Message-ID: <CAPg+sBj4ADfX+VObboUoO7AJ4ONVREX4R1H6TmCnrJX2m0+65g@mail.gmail.com>
To: ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: John Newbery <john@johnnewbery.com>, Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] Taproot proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2019 21:22:08 -0000
On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for =
segwit
> > v0 for compatibility reasons. Most wallets/exchanges/services now suppo=
rt 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 tapr=
oot 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 us=
er 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,
--=20
Pieter
|
