[Lightning-dev] Pay-to-Open and UX improvements

Bastien TEINTURIER 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
gmaxwell [1]:

* 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 [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.


[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 <eth3rs at 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
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191218/f50736d9/attachment.html>

More information about the Lightning-dev mailing list