diff options
| author | Greg Sanders <gsanders87@gmail.com> | 2019-09-16 12:18:35 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-09-16 16:18:51 +0000 |
| commit | 34b0cd4be7139a4e2db4f4235490192de016606b (patch) | |
| tree | 1f7368bee2db4678ccf54fefb187472b7d184d0f /4f/446b2490fcdc8659c0961ded28a67491361597 | |
| parent | 672d7919e946505c795a79334348c3d5ce94a76c (diff) | |
| download | pi-bitcoindev-34b0cd4be7139a4e2db4f4235490192de016606b.tar.gz pi-bitcoindev-34b0cd4be7139a4e2db4f4235490192de016606b.zip | |
Re: [bitcoin-dev] Taproot proposal
Diffstat (limited to '4f/446b2490fcdc8659c0961ded28a67491361597')
| -rw-r--r-- | 4f/446b2490fcdc8659c0961ded28a67491361597 | 344 |
1 files changed, 344 insertions, 0 deletions
diff --git a/4f/446b2490fcdc8659c0961ded28a67491361597 b/4f/446b2490fcdc8659c0961ded28a67491361597 new file mode 100644 index 000000000..3d7850bbf --- /dev/null +++ b/4f/446b2490fcdc8659c0961ded28a67491361597 @@ -0,0 +1,344 @@ +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>> I'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'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 <<a href=3D"mailto:bitcoin-dev@lists.li= +nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> 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>> A Taproot output is a SegWit output [...] = +=C2=A0with<br>> 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> 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> 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> 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> 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'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>> (native or P2SH-nested= +, see BIP141)<br><br>I'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 <<a href=3D"mailto:bitcoin-dev@list= +s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.= +org</a>> 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'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-- + |