Ethan Heilman [ARCHIVE] on Nostr: 📅 Original date posted:2019-12-18 📝 Original message: > > Responding below The ...

📅 Original date posted:2019-12-18
📝 Original message:
>
> Responding below

The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the
> signature as a single 64-bytes stack argument, let's add a small change to
> read
> the signature as two 32-bytes stack arguments: `R` first then `s`.
> Since Taproot already makes changes to this opcode, adding this small
> change
> seems to be quite simple and harmless (and this is the right time to
> propose
> such a change as we're still in the Taproot review process).
>

I very much in favor of a mechanism to enable outputs to enforce ECDSA
nonce reuse.

However I would argue against changing the behavior of OP_CHECKSIG. Subtly
changing the stack behavior of perhaps the most widely used and complex OP
code in Bitcoin is likely to result in bugs in systems that create and sign
transactions. Additionally making this new behavior only activate based on
context is even more likely to cause problems.

It would likely be safer to have this as a new OP code, say
OP_CHECKSPLITSIG.

Alternatively we could try to get OP_CAT approved. It is a very simple OP
code, which is easy to explain, generally useful and allows this feature
plus allows many other critical features.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/e7a5abd2/attachment.html>;