From eth3rs at gmail.com Wed Dec 18 14:35:39 2019 From: eth3rs at gmail.com (Ethan Heilman) Date: Wed, 18 Dec 2019 09:35:39 -0500 Subject: [Lightning-dev] Pay-to-Open and UX improvements In-Reply-To: References: <20191217144346.erlikoqqllxu4irx@ganymede> <3GiEjMd49K1cZukcBKrRpZE4xa0-GQ4andCz_4MIO3WHIjSdDEdPrOTwez7hJwHgHM9NUHzXaWoSGPd6m_71xoLJvZUEw1Cllcm6TfFb5Yo=@protonmail.com> Message-ID: > > 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: