<div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div></blockquote></div><div dir="auto">Responding below</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading the<br>signature as a single 64-bytes stack argument, let's add a small change to read<br>the signature as two 32-bytes stack arguments: `R` first then `s`.<br>Since Taproot already makes changes to this opcode, adding this small change<br>seems to be quite simple and harmless (and this is the right time to propose<br>such a change as we're still in the Taproot review process).<br></div></blockquote></div><div dir="auto"><br></div><div dir="auto">I  very much in favor of a mechanism to enable outputs to enforce ECDSA nonce reuse.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">It would likely be safer to have this as a new OP code, say OP_CHECKSPLITSIG.</div><div dir="auto"><br></div><div dir="auto">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.</div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"></div>
</blockquote></div></div>