path: root/4f/446b2490fcdc8659c0961ded28a67491361597

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 068441997
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 16 Sep 2019 16:18:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com
	[209.85.208.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B0B1B81A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 16 Sep 2019 16:18:48 +0000 (UTC)
Received: by mail-ed1-f49.google.com with SMTP id r4so619991edy.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 16 Sep 2019 09:18:48 -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; 
	bh=c+YUr63FSXjGpw+ij1s4xJsKZIz74PySuFM/ErX4xb8=;
	b=Yww6ltD4aw2xEW8NacL3F5e91UKQTV1lFxmBXOgyoSkqVoMtKzpD7kNSb1zWqABrlh
	QeTYrGyM5KwvVC2I7+d7lZesDgtQG2sQXN3SqjYbs+Ml6mGvTRALWARjK7gsrYbsbKhN
	y5/ouhu2Cx/2ff/UT68Cr9t9sK+VdI4CdSi52uMh78I4jjzLt/238ffnvyUyxKsMFp/b
	7sKhwGFICkqX88XjMJWjvckAjtgrdwglcXCAVjnwYeLVw7pW8yuYI98Za8xbcyjuSa6f
	01vIZRW5RAP7kNhE+pFb7Asddv3JjExRCQC0sSLJfm/m8AsrbhU+AwaZcGzll9blIO2c
	azOg==
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;
	bh=c+YUr63FSXjGpw+ij1s4xJsKZIz74PySuFM/ErX4xb8=;
	b=LLFxyfVLVnD9tpS042MUAFZT6xcuKJ0LZRn0sunNgvWSY5X/kCI9NFmiwRn9bLq0jG
	TS4h6IfoJkMWZQPrh8isIQqLQoZDzox6GNKxEHyIzZxDw9hV+Zu5ceP2blGkRG1BcD6y
	rv4kclXorLT30bB3292QMuRzZRqt8xfb4E3gFpuotfETaVDyUS7uFCP5l18L9Mkhb8Gl
	BySKG5ZBpYyYX8QNBob6CdyByaCg+Wg3xwL/WagtbzHO9pqmfuQQmjOmqitJULHxHpXT
	kQDsjHXOxLcPndR8DYS7SyNOA3Drw++hGcMagO5lpasZlkPulh/oAkYG8U6NnlsPtaYA
	t+hA==
X-Gm-Message-State: APjAAAWCpYwi4RXKTkzkikpmdr1O4ze/CrDYkicT628osHvkjWGlumba
	6UBHLLisoq1FWj2fnNGkoBlhVsYy5LXS/7+s9+QnFgIb
X-Google-Smtp-Source: APXvYqzfra49I5EJ3K384PluUkfHIj+e5/lu9pwli2I0sjdP6QY739Ib7lCJRTEVDAUBilQFW8s+g9hLtwh3ZA41sjA=
X-Received: by 2002:a17:906:434f:: with SMTP id
	z15mr827206ejm.214.1568650726995; 
	Mon, 16 Sep 2019 09:18:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
	<CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com>
In-Reply-To: <CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 16 Sep 2019 12:18:35 -0400
Message-ID: <CAB3F3DvdUhZXO+hWZxdS64hO3gQGwGUURur5CA5Fp4hgn7g5EQ@mail.gmail.com>
To: John Newbery <john@johnnewbery.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005bfbf50592adf57f"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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: Mon, 16 Sep 2019 16:18:51 -0000

--0000000000005bfbf50592adf57f
Content-Type: text/plain; charset="UTF-8"

> 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 Wed, May 22, 2019 at 10:30 AM John Newbery via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> > A Taproot output is a SegWit output [...]  with
> > 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=(x,y), a signer with the knowledge
> of k
> can sign for -P=(x,p-y) since -k is the secret key for that point.
> Encoding 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 the y
> value
> of the internal key P to be even (or high, or a quadratic residue). That
> 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
>     => witness program is 33 bytes, 32 possible leaf versions (one for
> each pair of 0xc0..0xff)
> 2. Q sign is explictly set in the witness program, P sign is implicitly
> even
>     => witness program is 33 bytes, 64 possible leaf versions (one for
> each 0xc0..0xff)
> 3. Q sign is explictly set in the control block, P sign is explicitly set
> in the control block
>     => witness program is 32 bytes, 16 possible leaf versions (one for
> each 4-tuple of 0xc0..0xff)
> 4. Q sign is explictly set in the control block, P sign is implicitly even
>     => witness program is 32 bytes, 32 possible leaf versions (one for
> pair of 0xc0..0xff)
>
> The current proposal uses (1). Using (3) or (4) would reduce the size of 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.
>
> (Credit to James Chiang for suggesting omitting the y sign from the public
> 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 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.
>
> On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev <
> bitcoin-dev@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 indistinguishable
>> 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.mediawiki
>> 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/2018-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 loss
>> 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
>

--0000000000005bfbf50592adf57f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; I&#39;d prefer to not support P2SH-nested TR. P2=
SH wrapping was useful for segwit</div>v0 for compatibility reasons. Most w=
allets/exchanges/services now support sending<br>to native segwit addresses=
 (<a href=3D"https://en.bitcoin.it/wiki/Bech32_adoption" target=3D"_blank">=
https://en.bitcoin.it/wiki/Bech32_adoption</a>) and that<br>will be even mo=
re true if Schnorr/<span class=3D"gmail-il">Taproot</span>=C2=A0activate in=
 12+ months time.<div><br></div>Apologies for necroing an ancient thread, b=
ut I&#39;m echoing my agreement with John here.<div>We still have plenty of=
 time to have ecosystem upgrade by the time taproot is likely to activate.<=
/div><div><div><br></div><div><br></div></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 22, 2019 at 10:30=
 AM John Newbery via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv dir=3D"ltr">Hi,<br><br>&gt; A Taproot output is a SegWit output [...] =
=C2=A0with<br>&gt; version number 1, and a 33-byte witness program whose fi=
rst byte is 0 or 1.<br><br>Given a secret key k and public key P=3D(x,y), a=
 signer with the knowledge of k<br>can sign for -P=3D(x,p-y) since -k is th=
e secret key for that point. Encoding the<br>y value of the public key ther=
efore adds no security. As an alternative to<br>providing the y value of th=
e taproot output key Q when constructing the taproot<br>output, the signer =
can provide it when signing. We can also restrict the y value<br>of the int=
ernal key P to be even (or high, or a quadratic residue). That gives<br>us =
4 options for how to set the y signs for P and Q.<br><br>1. Q sign is expli=
ctly set in the witness program, P sign is explicitly set in the control bl=
ock<br>=C2=A0 =C2=A0 =3D&gt; witness program is 33 bytes, 32 possible leaf =
versions (one for each pair of 0xc0..0xff)<br>2. Q sign is explictly set in=
 the witness program, P sign is implicitly even<br>=C2=A0 =C2=A0 =3D&gt; wi=
tness program is 33 bytes, 64 possible leaf versions (one for each 0xc0..0x=
ff)<br>3. Q sign is explictly set in the control block, P sign is explicitl=
y set in the control block<br>=C2=A0 =C2=A0 =3D&gt; witness program is 32 b=
ytes, 16 possible leaf versions (one for each 4-tuple of 0xc0..0xff)<br>4. =
Q sign is explictly set in the control block, P sign is implicitly even<br>=
=C2=A0 =C2=A0 =3D&gt; witness program is 32 bytes, 32 possible leaf version=
s (one for pair of 0xc0..0xff)<br><br>The current proposal uses (1). Using =
(3) or (4) would reduce the size of a<br>taproot output by one byte to be t=
he same size as a P2WSH output. That means<br>that it&#39;s not more expens=
ive for senders compared to sending to P2WSH.<br>=C2=A0<br>(Credit to James=
 Chiang for suggesting omitting the y sign from the public key and<br>to si=
pa for pointing out the 4 options above)<br><br>&gt; (native or P2SH-nested=
, see BIP141)<br><br>I&#39;d prefer to not support P2SH-nested TR. P2SH wra=
pping was useful for segwit<br>v0 for compatibility reasons. Most wallets/e=
xchanges/services now support sending<br>to native segwit addresses (<a hre=
f=3D"https://en.bitcoin.it/wiki/Bech32_adoption" target=3D"_blank">https://=
en.bitcoin.it/wiki/Bech32_adoption</a>) and that<br>will be even more true =
if Schnorr/Taproot activate in 12+ months time.<br></div><br><div class=3D"=
gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 6, 2019 at 2=
:36 PM Pieter Wuille via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">Hello everyone,<br>
<br>
Here are two BIP drafts that specify a proposal for a Taproot<br>
softfork. A number of ideas are included:<br>
<br>
* Taproot to make all outputs and cooperative spends indistinguishable<br>
from eachother.<br>
* Merkle branches to hide the unexecuted branches in scripts.<br>
* Schnorr signatures enable wallet software to use key<br>
aggregation/thresholds within one input.<br>
* Improvements to the signature hashing algorithm (including signing<br>
all input amounts).<br>
* Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support<br>
batch validation.<br>
* Tagged hashing for domain separation (avoiding issues like<br>
CVE-2012-2459 in Merkle trees).<br>
* Extensibility through leaf versions, OP_SUCCESS opcodes, and<br>
upgradable pubkey types.<br>
<br>
The BIP drafts can be found here:<br>
* <a href=3D"https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.medi=
awiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/sipa/bips/bl=
ob/bip-schnorr/bip-taproot.mediawiki</a><br>
specifies the transaction input spending rules.<br>
* <a href=3D"https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.me=
diawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/sipa/bips/=
blob/bip-schnorr/bip-tapscript.mediawiki</a><br>
specifies the changes to Script inside such spends.<br>
* <a href=3D"https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.medi=
awiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/sipa/bips/bl=
ob/bip-schnorr/bip-schnorr.mediawiki</a><br>
is the Schnorr signature proposal that was discussed earlier on this<br>
list (See <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2018-July/016203.html" rel=3D"noreferrer" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html</a>)<br>
<br>
An initial reference implementation of the consensus changes, plus<br>
preliminary construction/signing tests in the Python framework can be<br>
found on <a href=3D"https://github.com/sipa/bitcoin/commits/taproot" rel=3D=
"noreferrer" target=3D"_blank">https://github.com/sipa/bitcoin/commits/tapr=
oot</a>. All<br>
together, excluding the Schnorr signature module in libsecp256k1, the<br>
consensus changes are around 520 LoC.<br>
<br>
While many other ideas exist, not everything is incorporated. This<br>
includes several ideas that can be implemented separately without loss<br>
of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,<br>
which we&#39;re working on as an independent proposal.<br>
<br>
The document explains basic wallet operations, such as constructing<br>
outputs and signing. However, a wide variety of more complex<br>
constructions exist. Standardizing these is useful, but out of scope<br>
for now. It is likely also desirable to define extensions to PSBT<br>
(BIP174) for interacting with Taproot. That too is not included here.<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005bfbf50592adf57f--