Date: Tue, 17 Sep 2019 04:09:50 +0000
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
Cc: John Newbery <john@johnnewbery.com>
Subject: Re: [bitcoin-dev] Taproot proposal
Precedence: list

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