Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 07EEAD85 for ; 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 ; Thu, 27 Jun 2019 00:08:13 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id r185so751613iod.6 for ; 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: In-Reply-To: From: "Russell O'Connor" Date: Wed, 26 Jun 2019 20:08:01 -0400 Message-ID: To: Pieter Wuille , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
I have a comment about the 'input_index' 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.
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.
=

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'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't be so great.

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 'input_index= ' will suffice.

Given that adding 2 bytes to th= e signed transaction digest isn't a big=20 deal, it's probably better just to keep block limits and transaction li= mits=20 separate.

[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!

[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.

On Mon, May 6, 2019 at 2:36 PM Pieter Wuil= le 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/bl= ob/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/bl= ob/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/tapr= oot. 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/mail= man/listinfo/bitcoin-dev
--000000000000312a26058c42f59f--