Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2019-08-09 📝 Original message:On Fri, 9 Aug 2019 at ...
📅 Original date posted:2019-08-09
📝 Original message:On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
<bitcoin-dev at 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
📝 Original message:On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev
<bitcoin-dev at 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