📅 Original date posted:2018-11-23
📝 Original message: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:
DUP DUP CHECKSIG CODESEP CHECKSIG CODESEP CHECKSIG
with the idea being that it can be spent by providing any pub key and
three different signatures by that key, with the first sig committing
to a "codesep position" of 0, the second a "codesep position" of 4,
and the third a "codesep position" of 6? In each case, the signature
also commits to the full (possibly masked) script as well.
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:
NOINPUT -- lets the sig apply to different transactions
OP_MASK -- lets the different txes have variations in the script the
sig applies to
CODESEP -- lets you require different sigs for different parts of a
single script
MAST[0] -- provides alternative scripts, doesn't affect sigs
IF/etc -- provides control flow within a script, doesn't affect sigs
Cheers,
aj
[0] (I think I'm going to claim "MAST" stands for "merkelized alternative
script tree" these days, since they're not "abstract syntax trees")
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 18:15:19
in reply to nevent1q…66pw
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:15:19Event JSON
{
"id": "a6228a6de696a0f4f50bcd3c9e22d71ef992f6bbdb26bb4826844841ccb26e1c",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686161719,
"kind": 1,
"tags": [
[
"e",
"1bd7a781e2cfd166ff9a33b1bac5fde47a675384fad1a2f913ed308d62699fea",
"",
"root"
],
[
"e",
"d195585f150cbfee2949a6287a8ae96fe83f8702674851f92004814625443155",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2018-11-23\n📝 Original message:On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote:\n\u003e Given that we want to move away from OP_CODESEPARATOR, because each call to\n\u003e this operation effectively takes O(script-size) time, we need a replacement for\n\u003e the functionality it currently provides. While perhaps the original motivation\n\u003e for OP_CODESEPARTOR is surrounded in mystery, it currently can be used (or\n\u003e perhaps abused) for the task of creating signature that covers, not only which\n\u003e input is being signed, but which specific branch within that input Script code\n\u003e is being signed for.\n\nWould it be sufficient to sign the position within the script of the\nlast OP_CODESEPARATOR? That is, if your script is:\n\n DUP DUP CHECKSIG CODESEP CHECKSIG CODESEP CHECKSIG\n\nwith the idea being that it can be spent by providing any pub key and\nthree different signatures by that key, with the first sig committing\nto a \"codesep position\" of 0, the second a \"codesep position\" of 4,\nand the third a \"codesep position\" of 6? In each case, the signature\nalso commits to the full (possibly masked) script as well.\n\nI think that covers all the behaviour you can currently achieve with\nCODESEP (which is pretty limited since every sig effectively commits\nto the full redeem script, and you can't commit to subsets of the\nsignature/witness), and it keeps the things you can do with the various\nfeatures a bit orthogonal:\n\n NOINPUT -- lets the sig apply to different transactions\n OP_MASK -- lets the different txes have variations in the script the\n sig applies to\n CODESEP -- lets you require different sigs for different parts of a\n single script\n MAST[0] -- provides alternative scripts, doesn't affect sigs\n IF/etc -- provides control flow within a script, doesn't affect sigs\n\nCheers,\naj\n\n[0] (I think I'm going to claim \"MAST\" stands for \"merkelized alternative\n script tree\" these days, since they're not \"abstract syntax trees\")",
"sig": "e149bced714a47002d472e84a046afd105f21753162d4d08cc17fa689985760ab9742406dce936f78cefb233b08e011d1629a8c77fbe90c75d2988c964186d53"
}