<div dir="ltr"><div dir="ltr">Hi,<br><br>&gt; A Taproot output is a SegWit output [...]  with<br>&gt; version number 1, and a 33-byte witness program whose first byte is 0 or 1.<br><br>Given a secret key k and public key P=(x,y), a signer with the knowledge of k<br>can sign for -P=(x,p-y) since -k is the secret key for that point. Encoding the<br>y value of the public key therefore adds no security. As an alternative to<br>providing the y value of the 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 internal 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 explictly set in the witness program, P sign is explicitly set in the control block<br>    =&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>    =&gt; witness program is 33 bytes, 64 possible leaf versions (one for each 0xc0..0xff)<br>3. Q sign is explictly set in the control block, P sign is explicitly set in the control block<br>    =&gt; witness program is 32 bytes, 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>    =&gt; witness program is 32 bytes, 32 possible leaf versions (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 the same size as a P2WSH output. That means<br>that it&#39;s not more expensive for senders compared to sending to P2WSH.<br> <br>(Credit to James Chiang for suggesting omitting the y sign from the public key and<br>to sipa 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 wrapping was useful for segwit<br>v0 for compatibility reasons. Most wallets/exchanges/services now support sending<br>to native segwit addresses (<a href="https://en.bitcoin.it/wiki/Bech32_adoption" target="_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="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 6, 2019 at 2:36 PM Pieter Wuille via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="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="https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki" rel="noreferrer" target="_blank">https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki</a><br>
specifies the transaction input spending rules.<br>
* <a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki" rel="noreferrer" target="_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="https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki" rel="noreferrer" target="_blank">https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki</a><br>
is the Schnorr signature proposal that was discussed earlier on this<br>
list (See <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html" rel="noreferrer" target="_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="https://github.com/sipa/bitcoin/commits/taproot" rel="noreferrer" target="_blank">https://github.com/sipa/bitcoin/commits/taproot</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="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>