[Lightning-dev] Pay-to-Open and UX improvements
bastien at acinq.fr
Wed Dec 18 15:14:24 UTC 2019
Thanks Ethan, I agree on that.
Let me also share additional feedback I received on #bitcoin-wizards from
* Changing the behavior of OP_CHECKSIG is a no-go because using two stack
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 : 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.
Le mer. 18 déc. 2019 à 15:35, Ethan Heilman <eth3rs at gmail.com> a écrit :
> Responding below
> The core idea is to modify Tapscript's `OP_CHECKSIG`. Instead of reading
>> 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
>> seems to be quite simple and harmless (and this is the right time to
>> 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
> 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...
More information about the Lightning-dev