From bastien at acinq.fr Wed Dec 18 15:14:24 2019 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Wed, 18 Dec 2019 16:14:24 +0100 Subject: [Lightning-dev] Pay-to-Open and UX improvements In-Reply-To: References: <20191217144346.erlikoqqllxu4irx@ganymede> <3GiEjMd49K1cZukcBKrRpZE4xa0-GQ4andCz_4MIO3WHIjSdDEdPrOTwez7hJwHgHM9NUHzXaWoSGPd6m_71xoLJvZUEw1Cllcm6TfFb5Yo=@protonmail.com> Message-ID: 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 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. > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: