path: root/a3/43c16040907605105eb20a222089bb3e72617c

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E13AC4E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 17 Sep 2019 04:10:01 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
	[185.70.40.135])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04F6E81A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 17 Sep 2019 04:09:59 +0000 (UTC)
Date: Tue, 17 Sep 2019 04:09:50 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1568693397;
	bh=aC5Gx8VvBgQIJ8GCHERtZWoo4OMMAWCPkihHdwcMKKo=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=XufQn31D1FIpparwvfXaJorNlCqQMcUo8xhIuq5bzPwhjuy1PwitELoH87rGKvopx
	c0xB5F7va7gENqpuqY3Lpi5VotYtiq/XPvwbXiqID1O1d4Qld/8k2+pkkSsyNdZlXE
	hdi/tC7Jiq3dNIiVn55ec0HlhhqU5PYdC8W7Ugx8=
To: Greg Sanders <gsanders87@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <A7FKsw5tH-KnsBfn-IVS2N1qJpjhh4ALsdO3nupkio_zeymKbmOFiNgpVVxkWXZIx6EqurdRHkmgVDtXKddLDhLBFq-3aebiaH8_BdNzDu0=@protonmail.com>
In-Reply-To: <CAB3F3DvdUhZXO+hWZxdS64hO3gQGwGUURur5CA5Fp4hgn7g5EQ@mail.gmail.com>
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
	<CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com>
	<CAB3F3DvdUhZXO+hWZxdS64hO3gQGwGUURur5CA5Fp4hgn7g5EQ@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW 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>
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: Tue, 17 Sep 2019 04:10:01 -0000

Good morning Greg and John,

I am not as sanguine here; SegWit activation was already delayed relative t=
o commonly-broadcast expectations, yet many services *still* do not support=
 sending to SegWit v0 addresses even now.

On the other hand, the major benefit of taproot is the better privacy and h=
omogeneity afforded by Taproot, and supporting both P2SH-wrapped and non-wr=
apped SegWit v1 addresses simply increases the number of places that a user=
 may be characterized and potentially identified.

Thus while I disagree with your reasoning, I do agree with your conclusion:=
 no P2SH-wrapped SegWit v1.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, September 17, 2019 12:18 AM, Greg Sanders via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> wrote:

> > 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) a=
nd that
> will be even more true if Schnorr/Taproot=C2=A0activate in 12+ months tim=
e.
>
> Apologies for necroing an ancient thread, but I'm echoing my agreement wi=
th John here.
> We still have plenty of time to have ecosystem upgrade by the time taproo=
t is likely to activate.
>
> On Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org> wrote:
>
> > Hi,
> >
> > > A Taproot output is a SegWit output [...] =C2=A0with
> > > version number 1, and a 33-byte witness program whose first byte is 0=
 or 1.
> >
> > Given a secret key k and public key P=3D(x,y), a signer with the knowle=
dge of k
> > can sign for -P=3D(x,p-y) since -k is the secret key for that point. En=
coding the
> > y value of the public key therefore adds no security. As an alternative=
 to
> > providing the y value of the taproot output key Q when constructing the=
 taproot
> > output, the signer can provide it when signing. We can also restrict th=
e y value
> > of the internal key P to be even (or high, or a quadratic residue). Tha=
t gives
> > us 4 options for how to set the y signs for P and Q.
> >
> > 1. Q sign is explictly set in the witness program, P sign is explicitly=
 set in the control block
> > =C2=A0 =C2=A0 =3D> witness program is 33 bytes, 32 possible leaf versio=
ns (one for each pair of 0xc0..0xff)
> > 2. Q sign is explictly set in the witness program, P sign is implicitly=
 even
> > =C2=A0 =C2=A0 =3D> witness program is 33 bytes, 64 possible leaf versio=
ns (one for each 0xc0..0xff)
> > 3. Q sign is explictly set in the control block, P sign is explicitly s=
et in the control block
> > =C2=A0 =C2=A0 =3D> witness program is 32 bytes, 16 possible leaf versio=
ns (one for each 4-tuple of 0xc0..0xff)
> > 4. Q sign is explictly set in the control block, P sign is implicitly e=
ven
> > =C2=A0 =C2=A0 =3D> witness program is 32 bytes, 32 possible leaf versio=
ns (one for pair of 0xc0..0xff)
> >
> > The current proposal uses (1). Using (3) or (4) would reduce the size o=
f a
> > taproot output by one byte to be the same size as a P2WSH output. That =
means
> > that it's not more expensive for senders compared to sending to P2WSH.
> > =C2=A0
> > (Credit to James Chiang for suggesting omitting the y sign from the pub=
lic key and
> > to sipa for pointing out the 4 options above)
> >
> > > (native or P2SH-nested, see BIP141)
> >
> > 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.
> >
> > On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
> >
> > > Hello everyone,
> > >
> > > Here are two BIP drafts that specify a proposal for a Taproot
> > > softfork. A number of ideas are included:
> > >
> > > * Taproot to make all outputs and cooperative spends indistinguishabl=
e
> > > from eachother.
> > > * Merkle branches to hide the unexecuted branches in scripts.
> > > * Schnorr signatures enable wallet software to use key
> > > aggregation/thresholds within one input.
> > > * Improvements to the signature hashing algorithm (including signing
> > > all input amounts).
> > > * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
> > > batch validation.
> > > * Tagged hashing for domain separation (avoiding issues like
> > > CVE-2012-2459 in Merkle trees).
> > > * Extensibility through leaf versions, OP_SUCCESS opcodes, and
> > > upgradable pubkey types.
> > >
> > > The BIP drafts can be found here:
> > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
> > > specifies the transaction input spending rules.
> > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawi=
ki
> > > specifies the changes to Script inside such spends.
> > > * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
> > > is the Schnorr signature proposal that was discussed earlier on this
> > > list (See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
8-July/016203.html)
> > >
> > > An initial reference implementation of the consensus changes, plus
> > > preliminary construction/signing tests in the Python framework can be
> > > found on https://github.com/sipa/bitcoin/commits/taproot. All
> > > together, excluding the Schnorr signature module in libsecp256k1, the
> > > consensus changes are around 520 LoC.
> > >
> > > While many other ideas exist, not everything is incorporated. This
> > > includes several ideas that can be implemented separately without los=
s
> > > of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT=
,
> > > which we're working on as an independent proposal.
> > >
> > > The document explains basic wallet operations, such as constructing
> > > outputs and signing. However, a wide variety of more complex
> > > constructions exist. Standardizing these is useful, but out of scope
> > > for now. It is likely also desirable to define extensions to PSBT
> > > (BIP174) for interacting with Taproot. That too is not included here.
> > >
> > > Cheers,
> > >
> > > --
> > > Pieter
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev