public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Elichai Turkel <elichai.turkel@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot proposal
Date: Fri, 9 Aug 2019 11:29:55 -0700	[thread overview]
Message-ID: <CAPg+sBgyhjRmVdtC1bGWkpaTtMqQRsCqKjFB=LU_fcMYUJc6jA@mail.gmail.com> (raw)
In-Reply-To: <CALN7hCJ7dCER9zaQbXvT4AVt95cZwBsQcTX8XvvZwF-1xa-V4w@mail.gmail.com>

On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi,

Since the idea of implicitly even pubkeys has potentially more general
implications, I've started a separate thread [1] about that idea.

> I want to add to John Newbery's suggestion of using implicit even/odd only public keys and tweaked public keys in taproot and suggest the following:
> If everything is implicit then the only reason for the first byte of the control block(`c[0]`) is the tapscript leaf version.

That's unfortunately not correct. If we want to maintain
batch-verifiability of the taproot tweaking (the Q = P + H(P,m)G
relation), we still need a bit in the control block to convey whether
a negation was necessary to make P+H(P,m)G even, even if P and Q both
have implied-even Y coordinates. Not doing that would require
exploring 2^n combinations to batch verify n relations, obviously
destroying any performance savings the batch verification had in the
first place.

> I suggest that this is moved to be the first OP_CODE of the tapscript itself (i.e. OP_0/OP_1 etc.)
> That way having the script *tells* you what does it mean without needing to check the control block.
> That way there's a separation between the tapscript+leaf version and the control block being the merkle path to the script.

If we keep the leaf version idea (it's possible to instead just rely
entirely on OP_SUCCESSx, and drop leaf versions), my preference is to
still keep it separate from script, though just for a fairly banal
reason: that way the script consists entirely of opcodes and can be
treated uniformly by debug tools, rather than needing to treat the
first byte special. I do understand your preference too, but I don't
know how it weighs up.

  [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html

Cheers,

-- 
Pieter


  reply	other threads:[~2019-08-09 18:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-09 14:58 [bitcoin-dev] Taproot proposal Elichai Turkel
2019-08-09 18:29 ` Pieter Wuille [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-05-06 17:57 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
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

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='CAPg+sBgyhjRmVdtC1bGWkpaTtMqQRsCqKjFB=LU_fcMYUJc6jA@mail.gmail.com' \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elichai.turkel@gmail.com \
    /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