📅 Original date posted:2018-11-23
📝 Original message:On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns <aj at erisian.com.au> wrote:
> On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > Given that we want to move away from OP_CODESEPARATOR, because each call
> to
> > this operation effectively takes O(script-size) time, we need a
> replacement for
> > the functionality it currently provides. While perhaps the original
> motivation
> > for OP_CODESEPARTOR is surrounded in mystery, it currently can be used
> (or
> > perhaps abused) for the task of creating signature that covers, not only
> which
> > input is being signed, but which specific branch within that input
> Script code
> > is being signed for.
>
> Would it be sufficient to sign the position within the script of the
> last OP_CODESEPARATOR? That is, if your script is:
>
> I think that covers all the behaviour you can currently achieve with
> CODESEP (which is pretty limited since every sig effectively commits
> to the full redeem script, and you can't commit to subsets of the
> signature/witness), and it keeps the things you can do with the various
> features a bit orthogonal:
>
Thanks for bringing this up. I was thinking the same thing as well, that
yes that should be sufficient to cover the semantics of OP_CODESEPARATOR.
Though to be more precise you would sign the position of the last
_executed_ OP_CODESEPARATOR.
That said, while I agree the above is a superior realization of the
OP_CODESEPARATOR, given that we are probably going to support
OP_CODESEPARATOR inside legacy P2SH scripts indefinitely, it is probably
better to keep the existing akward implementation of OP_CODESEPARATOR in
future versions of Script. (At least until we decide to stop mangling the
Script consensus code with more and more flag combinations and decide it is
better to cut and paste code for new versions of Script to help ensure we
don't make consensus changes to legacy behaviour).
> [0] (I think I'm going to claim "MAST" stands for "merkelized alternative
> script tree" these days, since they're not "abstract syntax trees")
>
:thumbs-up:
Sorry for hijacking the thread about OP_MASK and friends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181123/d6f9489a/attachment-0001.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:15:20
in reply to nevent1q…f2sk
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:15:20Event JSON
{
"id": "119c642cf02db574d795bd29f34831d4296e1984fe750bf6d0a6c7344ebc541c",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161720,
"kind": 1,
"tags": [
[
"e",
"1bd7a781e2cfd166ff9a33b1bac5fde47a675384fad1a2f913ed308d62699fea",
"",
"root"
],
[
"e",
"a6228a6de696a0f4f50bcd3c9e22d71ef992f6bbdb26bb4826844841ccb26e1c",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2018-11-23\n📝 Original message:On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev\n\u003e wrote:\n\u003e \u003e Given that we want to move away from OP_CODESEPARATOR, because each call\n\u003e to\n\u003e \u003e this operation effectively takes O(script-size) time, we need a\n\u003e replacement for\n\u003e \u003e the functionality it currently provides. While perhaps the original\n\u003e motivation\n\u003e \u003e for OP_CODESEPARTOR is surrounded in mystery, it currently can be used\n\u003e (or\n\u003e \u003e perhaps abused) for the task of creating signature that covers, not only\n\u003e which\n\u003e \u003e input is being signed, but which specific branch within that input\n\u003e Script code\n\u003e \u003e is being signed for.\n\u003e\n\u003e Would it be sufficient to sign the position within the script of the\n\u003e last OP_CODESEPARATOR? That is, if your script is:\n\u003e\n\u003e I think that covers all the behaviour you can currently achieve with\n\u003e CODESEP (which is pretty limited since every sig effectively commits\n\u003e to the full redeem script, and you can't commit to subsets of the\n\u003e signature/witness), and it keeps the things you can do with the various\n\u003e features a bit orthogonal:\n\u003e\n\nThanks for bringing this up. I was thinking the same thing as well, that\nyes that should be sufficient to cover the semantics of OP_CODESEPARATOR.\nThough to be more precise you would sign the position of the last\n_executed_ OP_CODESEPARATOR.\n\nThat said, while I agree the above is a superior realization of the\nOP_CODESEPARATOR, given that we are probably going to support\nOP_CODESEPARATOR inside legacy P2SH scripts indefinitely, it is probably\nbetter to keep the existing akward implementation of OP_CODESEPARATOR in\nfuture versions of Script. (At least until we decide to stop mangling the\nScript consensus code with more and more flag combinations and decide it is\nbetter to cut and paste code for new versions of Script to help ensure we\ndon't make consensus changes to legacy behaviour).\n\n\n\u003e [0] (I think I'm going to claim \"MAST\" stands for \"merkelized alternative\n\u003e script tree\" these days, since they're not \"abstract syntax trees\")\n\u003e\n\n:thumbs-up:\n\nSorry for hijacking the thread about OP_MASK and friends.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181123/d6f9489a/attachment-0001.html\u003e",
"sig": "9eef7b4576b3f1903d7d95c57884baa3a35dade0eaf2f7464c55c23ec1dc9a308ee759d01d24e5536327fcd56c658d5e16c6a7631c87d714fa5afe2678e326c0"
}