📅 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
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:45:52
in reply to nevent1q…c3f2
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:45:52Event JSON
{
"id": "e1ccb5ac94210e86eb8c1c0fbfecdd79f73f0cc4e097a47671b031bf13cb2e46",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314752,
"kind": 1,
"tags": [
[
"e",
"9dffd851f36e0464b9b84a18f034d9a166bd96caa924994430620e4b51393055",
"",
"root"
],
[
"e",
"f04604344e20378f7797f68965bff342a2b340279fbae348bf80d9253be13b7d",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2016-03-10\n📝 Original message:\nHi Nicolas,\n\nOn Tue, Mar 08, 2016 at 01:44:05PM +0900, Nicolas Dorier wrote:\n\u003e I am catching up with the latest dev of lightning. I thought you\n\u003e wanted SIGHASH_NOPINPUT in order to fix the problem of storage\n\u003e requirement.\n\u003e [...]\n\u003e I re-read slowly your post on bitcoin-dev about SIGHASH_NOINPUT, and\n\u003e noticed the problem it was to fix was for third party monitoring.\n\nYes, SIGHASH_NOINPUT is for the storage requirement. I was talking about\nan implementation detail for using OP_CODESEPARATOR to ensure that the\nsignature is valid for multiple types of script outputs.\n\nAs a side point, I think to clarify to the rest of the list what Nicolas\nhas discovered for those who are skimming since I find novel/unusual use\nof OP_CODESEPARATOR interesting, I believe Nicolas was talking about\nnoticing that an aspect of OP_CODESEPARATOR is you can use it to enforce\nbranch execution. For LN, however, the script can be made compact\nwithout OP_CODESEPARATOR.\n\nE.g. if part of the script looked like (ignore optimizations for a sec!)\n\n\u003calicePubkey\u003e #used for OP_CHECKSIG\nOP_IF\n\t[some kind of conditions, e.g. OP_CLTV, OP_HASH160, etc.]\n\tOP_CODESEPARATOR\n\tOP_CHECKSIG\nOP_ELSE\n\t[OTHER conditions, e.g. OP_CLTV, OP_HASH160, etc.]\n\tOP_CODESEPARATOR\n\tOP_CHECKSIG\nOP_END\n\nIn this situation, a single pubkey can enforce execution of a particular\ncodepath. The codeseparator can enforce whether the first IF path is\nexecuted or the ELSE statement, since a signature can only be valid for\none of the two paths. This is achieved since codeseperator selects which\npart of the script to sign, which is a very interesting result.\n\nWhile this doesn't allow you do things you weren't able to before, this\ndoes offer potential space savings. It's possible to enforce code\nexecution with slightly larger scripts without using OP_CODESEPARATOR by\nusing two different pubkeys or by moving the conditions to be a nested\nOP_IF statement.\n\nThis type of construction is interesting because there can be\nmulti-party multi-signature situations where a party only wants to sign\noff on particular conditions are guaranteed to be executed, especially\nif there is some interactive communication and out-of-band conditions\nfor signing.\n\n-- \nJoseph Poon",
"sig": "3a9c3b9700822580e08bb214c95f43a1e91ffe9e2efab4839ef78f3edd10a81e5c164634b7e44a6baab3e5ab83eaad50de3045be590aab6bfe5954e2662d24a7"
}