John Newbery [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-22 📝 Original message:Hi, > A Taproot output is ...
📅 Original date posted:2019-05-22
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190522/74fc5f35/attachment-0001.html>;
📝 Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190522/74fc5f35/attachment-0001.html>;