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