Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-03-10 📝 Original message: Hi Nicolas, On Tue, Mar ...

📅 Original date posted:2016-03-10
📝 Original message:
Hi Nicolas,

On Tue, Mar 08, 2016 at 01:44:05PM +0900, Nicolas Dorier wrote:
> I am catching up with the latest dev of lightning. I thought you
> wanted SIGHASH_NOPINPUT in order to fix the problem of storage
> requirement.
> [...]
> I re-read slowly your post on bitcoin-dev about SIGHASH_NOINPUT, and
> noticed the problem it was to fix was for third party monitoring.

Yes, SIGHASH_NOINPUT is for the storage requirement. I was talking about
an implementation detail for using OP_CODESEPARATOR to ensure that the
signature is valid for multiple types of script outputs.

As a side point, I think to clarify to the rest of the list what Nicolas
has discovered for those who are skimming since I find novel/unusual use
of OP_CODESEPARATOR interesting, I believe Nicolas was talking about
noticing that an aspect of OP_CODESEPARATOR is you can use it to enforce
branch execution. For LN, however, the script can be made compact
without OP_CODESEPARATOR.

E.g. if part of the script looked like (ignore optimizations for a sec!)

<alicePubkey> #used for OP_CHECKSIG
OP_IF
[some kind of conditions, e.g. OP_CLTV, OP_HASH160, etc.]
OP_CODESEPARATOR
OP_CHECKSIG
OP_ELSE
[OTHER conditions, e.g. OP_CLTV, OP_HASH160, etc.]
OP_CODESEPARATOR
OP_CHECKSIG
OP_END

In this situation, a single pubkey can enforce execution of a particular
codepath. The codeseparator can enforce whether the first IF path is
executed or the ELSE statement, since a signature can only be valid for
one of the two paths. This is achieved since codeseperator selects which
part of the script to sign, which is a very interesting result.

While this doesn't allow you do things you weren't able to before, this
does offer potential space savings. It's possible to enforce code
execution with slightly larger scripts without using OP_CODESEPARATOR by
using two different pubkeys or by moving the conditions to be a nested
OP_IF statement.

This type of construction is interesting because there can be
multi-party multi-signature situations where a party only wants to sign
off on particular conditions are guaranteed to be executed, especially
if there is some interactive communication and out-of-band conditions
for signing.

--
Joseph Poon