Hi Jeremy,
Cool idea, I had a similar one myself a while back. Shows that great chefs
think alike ;). Here're some questions that came to mind as I was reviewing
the doc.
First, why accept only x-only keys?
From the PoV of Bitcoin Script today, they aren't used anywhere within the
execution environment. They also add some complexity to protocols that need
to accept them as input for further manipulation. They are indeed used for
Taproot output public keys, but those keys don't ever make their way down
into Script as an op code argument.
The musig2 BIP originally accepted x-only keys as input, but was switched to
instead accept normal compressed public keys in version v0.8.0 [1]. The
switch over enabled some simplifications in the BIP, as it enabled
eliminating one of the accumulator variables. For more details, see the
discussion that led to this change [2].
This comment from Tim resonates with my experience wrangling with bugs
introduced by improper/implicit handling of x-only keys over the years:
> Sigh yeah, x-only keys save a byte on chain but it seems the price we pay
> is a high engineering complexity. I think it's fair to say that noone had
> really anticipated this [1].
Second, why fail if the passed scalar is greater than the curve order vs
just reducing modulo the order and using that value?
This would mean that in some cases, the direct value of a hash can't be used
as the scalar tweak. The probability of this happening for sha256 outputs is
very low, but it presents developers with yet another thing to keep in mind
in order to use the op code safely.
You bring up the point that this allows the side stepping of a new source of
witness malleability, but in the year of Satoshi 16 (2025), aside from relay
nuisance shenanigans, is this something developers still need to care about?
Third, why allocate a cost of 50 op cost vs something lower to better
account for the difference in operation vs normal `OP_CHECKSIG`?
Validating a BIP-340 signature requires an extra scalar base mult
(ignoring the Strauss-Shamir trick for double scalar mult for a sec) vs
`OP_TWEAKADD` as it's defined in your draft BIP. As a result, one could
argue that the op code should have a lower cost vs `OP_CHECKSIG`.
-- Laolu
[1]:
https://github.com/jonasnick/bips/pull/37 [2]:
https://github.com/jonasnick/bips/issues/32