<div dir="ltr">Thanks Ethan, I agree on that.<div><br><div>Let me also share additional feedback I received on #bitcoin-wizards from gmaxwell [1]:</div><div><br></div><div>* Changing the behavior of OP_CHECKSIG is a no-go because using two stack arguments </div><div>  instead of one increases the witness size</div></div><div>* This is better done as a new opcode as you suggest</div><div>* OP_CAT and friends were intentionally left out of Taproot (too general, needs more analysis)</div><div>* But this OP_CHECKSPLITSIG is very constrained so may be ok?</div><div>* It does NOT protect against a finney attack [2]: protocols leveraging that would need to take</div><div>  such attacks into account in the incentive analysis</div><div>* It only protects against a double-spend if you disallow Patrick from "emptying" this UTXO via</div><div>  Lightning before double-spending</div><div><br></div><div>I still believe there are good use-cases for this for off-chain protocols, so I'll keep fleshing it out.</div><div>I am interested in more feedback about the scheme, potential other attack vectors, potential other</div><div>use-cases, anything you may find relevant to the discussion.</div><div><br></div><div>Cheers,</div><div>Bastien</div><div><br></div><div>[1] <a href="https://freenode.irclog.whitequark.org/bitcoin-wizards/2019-12-18">https://freenode.irclog.whitequark.org/bitcoin-wizards/2019-12-18</a></div><div>[2] <a href="https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack">https://bitcoin.stackexchange.com/questions/4942/what-is-a-finney-attack</a></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 18 déc. 2019 à 15:35, Ethan Heilman <<a href="mailto:eth3rs@gmail.com">eth3rs@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div>
</blockquote></div></div>
</blockquote></div>