public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: John Newbery <john@johnnewbery.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Wed, 22 May 2019 10:14:44 -0400	[thread overview]
Message-ID: <CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBg6Gg8b7hPogC==fehY3ZTHHpQReqym2fb4XXWFpMM-pQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6081 bytes --]

  parent reply	other threads:[~2019-05-22 14:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 17:57 [bitcoin-dev] Taproot proposal Pieter Wuille
2019-05-06 20:17 ` Luke Dashjr
2019-05-07 20:42   ` Sjors Provoost
2019-05-08  4:37     ` ZmnSCPxj
2019-05-08  5:16       ` ZmnSCPxj
2019-05-08 23:06     ` Pieter Wuille
2019-05-18 17:51       ` ZmnSCPxj
2019-05-08  3:44   ` ZmnSCPxj
2019-05-09 16:56     ` Johnson Lau
2019-05-10  5:38       ` ZmnSCPxj
2019-05-08  4:49   ` Anthony Towns
2019-05-08 13:10   ` Luke Dashjr
2019-05-21 17:20 ` Russell O'Connor
2019-05-23  2:06   ` Pieter Wuille
2019-05-23  2:32     ` Russell O'Connor
2019-05-22 14:14 ` John Newbery [this message]
2019-09-16 16:18   ` Greg Sanders
2019-09-17  4:09     ` ZmnSCPxj
2019-09-18 21:21       ` Pieter Wuille
2019-06-27  0:08 ` Russell O'Connor
2019-06-28  9:49   ` Anthony Towns
2019-06-28 11:16     ` Russell O'Connor
2019-08-09 14:58 Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFmfg2tV+_M2_HD-GO1jbnufSLAW+K36LCXRNL9R_-0FPpNQVA@mail.gmail.com \
    --to=john@johnnewbery.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox