path: root/39/c13b44defc036e1e015a1523b6a4b7f6926798

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 07EEAD85
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 00:08:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f43.google.com (mail-io1-f43.google.com
	[209.85.166.43])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1902D82D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 27 Jun 2019 00:08:13 +0000 (UTC)
Received: by mail-io1-f43.google.com with SMTP id r185so751613iod.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 26 Jun 2019 17:08:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream.io; s=google;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=RkGQ4FIi/1x+Pd0NWxq32LW/DxET9VTWggJUpvwtI2U=;
	b=KFH9D177iSsFEDgjJyPE6c9nwW9dIFNCAS/h2iQHjfY7CLu7t4IydAQDC+aEr5ta8D
	nOgukiFd3cvKte+X6HTGLoHjiHWTmZawT1Vhqj8bxalKhCbMySfH1Ws/64HCxmDgPNwY
	4LwNfXUJa6xCVmFwQmjkRQL0VcM7bqxdxSYcg=
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=RkGQ4FIi/1x+Pd0NWxq32LW/DxET9VTWggJUpvwtI2U=;
	b=l3JVcohRdSD9Csd4RmNpaS7bGY/zXdtvrmZ9PwTkK3O0yxSxZj3iQpqOq0eZlgoYMg
	8HL/KVq7Kforduk3qL0R7/vZcX8bi41VjdGTIf9Gjb5J9mFsnyI7QeOPY5D/BPGy1nBx
	OCWsmxHkMGK7Cx/BVd2Sjr6Hsa2bgBe3xQ2G9hOTUj0UOLaW8mBB3e7mcKvVwpGL5j2j
	zIXr/vf7tvYdEkucs6hspW8w3oazym8HDU4kBzKT/MqoqKFrjZ8NoLcnovWCtC69tsgf
	86ueBNLFJ7QkZ7Eu6aHjtu9scxRdjtHjoYnGZWptlw/TnbloSKmsTozOT6gVycHfscLd
	Fqeg==
X-Gm-Message-State: APjAAAURLCrbizkrko5Ifcy+cI2/m0SpzEG0BReOKaq3I/G3MLp3xEmI
	LKRr/OBZ9McI7wcqVkEvcH86Bq08QgdafeNTdIiKDg==
X-Google-Smtp-Source: APXvYqwY5F7G65qwWsmJCLWGJ6tT3u1biMyurN/9PCEQXoLsHDNEJqUPragb5L3XZi+uMR6kXUzKflcuWvK5OYHAFCM=
X-Received: by 2002:a5e:aa15:: with SMTP id s21mr1068671ioe.221.1561594092916; 
	Wed, 26 Jun 2019 17:08:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
In-Reply-To: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 26 Jun 2019 20:08:01 -0400
Message-ID: <CAMZUoKnniSEy4RM2DWCRxzVyYsGJ3Rbw4sbFv0zxuPi9gwoXYA@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000312a26058c42f59f"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	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
X-Mailman-Approved-At: Thu, 27 Jun 2019 03:17:17 +0000
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: Thu, 27 Jun 2019 00:08:15 -0000

--000000000000312a26058c42f59f
Content-Type: text/plain; charset="UTF-8"

I have a comment about the 'input_index' of the transaction digest for
taproot signatures.  It is currently listed as 2 bytes.  I think it would
be better to expand that to 4 bytes.
The two byte limit is derived from the block size / weight limit, which
limits the maximum size of a transaction, which in turn, due to a minimum
size of an inputs, places a limit on the maximum number of inputs.

However, I think it is a mistake to mix limits from the block layer into
the transaction layer of the consensus rules.  For example, I believe that,
as it stands currently, if we wanted to hardfork an increase in the block
weight limit, doing so wouldn't have any impact on the transaction layer
and we could transparently manage larger transactions with the current
transaction format [2].  However if we start incorporating the block limits
into the transaction layer, then we run the risk of such a hard fork
needing to also make consensus changes in the transaction
format/interpretation if we wanted to handle larger transaction sizes,
which, while doable, wouldn't be so great.

The current transaction format limits the number of inputs (and the number
of outputs) to 2^32-1 or less [1].  So using 4 bytes for the 'input_index'
will suffice.

Given that adding 2 bytes to the signed transaction digest isn't a big
deal, it's probably better just to keep block limits and transaction limits
separate.

[1]The var-integer field for the number of inputs (and the number of
outputs) in a transaction looks like it should allow upto 2^64-1 inputs;
however this is an illusion.  The P2P rules dictate that these values are
immediately taken modulo 2^32 after decoding.  For example, if the number
of inputs is a var-integer encoding of 0x0100000001, it is actually just a
non-canonical way of encoding that there is 1 input.  Try this at home!

[2]If we were to hardfork an increase in the block weight limit, we would
probably want to still keep the limit on the size of transactions that
consume legacy UTXOs in order to avoid the quadratic computation problems
that plagues the legacy transaction digest.

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
>

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

<div dir=3D"ltr"><div>I have a comment about the &#39;input_index&#39; of t=
he transaction digest for taproot signatures.=C2=A0 It is currently listed =
as 2 bytes.=C2=A0 I think it would be better to expand that to 4 bytes.</di=
v><div>The two byte limit is derived from the block size / weight limit, wh=
ich limits the maximum size of a transaction, which in turn, due to a minim=
um size of an inputs, places a limit on the maximum number of inputs.</div>=
<div><br></div><div>However, I think it is a mistake to mix limits from the=
 block layer into the transaction layer of the consensus rules.=C2=A0 For e=
xample,  I believe that, as it stands currently, if we wanted to hardfork a=
n increase in the block weight limit, doing so wouldn&#39;t have any impact=
 on the transaction layer and we could transparently manage larger transact=
ions with the current transaction format [2].=C2=A0 However if we start inc=
orporating the block limits into the transaction layer, then we run the ris=
k of such a hard fork needing to also make consensus changes in the transac=
tion format/interpretation if we wanted to handle larger transaction sizes,=
 which, while doable, wouldn&#39;t be so great.</div><div><br></div>The cur=
rent transaction format limits the number of inputs (and the number of outp=
uts) to 2^32-1 or less [1].=C2=A0 So using 4 bytes for the &#39;input_index=
&#39; will suffice.<div><br></div><div><div>Given that adding 2 bytes to th=
e signed transaction digest isn&#39;t a big=20
deal, it&#39;s probably better just to keep block limits and transaction li=
mits=20
separate.<br></div><div><br></div>[1]The var-integer field for the number o=
f inputs (and the number of outputs) in a transaction looks like it should =
allow upto 2^64-1 inputs; however this is an illusion.=C2=A0 The P2P rules =
dictate that these values are immediately taken modulo 2^32 after decoding.=
=C2=A0 For example, if the number of inputs is a var-integer encoding of 0x=
0100000001, it is actually just a non-canonical way of encoding that there =
is 1 input.=C2=A0 Try this at home!</div><div><br></div><div>[2]If we were =
to hardfork an increase in the block weight limit, we would probably want t=
o still keep the limit on the size of transactions that consume legacy UTXO=
s in order to avoid the quadratic computation problems that plagues the leg=
acy transaction digest.<br></div></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 Wuil=
le via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">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>

--000000000000312a26058c42f59f--