Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-12 📝 Original message:On Wed, Dec 12, 2018 at ...
📅 Original date posted:2018-12-12
📝 Original message:On Wed, Dec 12, 2018 at 08:12:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> > Here is a combined proposal:
> > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
> > and SIGHASH_SCRIPTMASK.
> > * A new opcode OP_MASK is added, which acts as a NOP during execution.
> > * The sighash is computed like in BIP143, but:
> > * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> > the subsequent opcode/push is removed.
> I'm asking on-list because I'm sure I'm not the only confused one.
> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
> perform mask-removal for signing?
The way I'm thinking about it is there's four amounts of knowledge you
could have about the input you're spending at the time you generate a
signature:
ALL: you know everything about every input for this tx
SINGLE: you know everything about the input you're signing for, but
not necessarily the others
SCRIPTPUBKEY: you know the exact scriptPubKey you're trying to satisfy, but
don't know the txid
SCRIPTMASK: you don't know the txid, don't know the scriptPubKey, don't
know the other taproot branches, and maybe don't even know the masked
out terms in the script -- but you do know the structure of the
script, and the non-masked terms
There's no value to masking in any but the final case -- the txid and
scriptPubKey commit to the full scriptcode already, so also signing the
scriptcode is just belt-and-suspenders protection.
(It might be that the "SCRIPTPUBKEY" option isn't very useful in
practice; maybe you'll always either know the txid, or need to mask
something?)
> And I am struggling to understand the role of scriptmask in a taproot
> world, where the alternate script is both hidden and general?
In a taproot world, your scriptPubKey is a point P=Q+H(Q,S)*G, where S
is a merkle root of possibly many scripts, and is spendable either by:
sig(P)
Q, path(S,script), script, witness(script)
SCRIPTMASK lets you prepare a signature for one particular script in
advance, even before you've decided what the other scripts are (and even
what the base point Q is), let alone built an actual transaction.
At least, that's my current understanding; and I think it makes sense...
Cheers,
aj
Published at
2023-06-07 18:15:41Event JSON
{
"id": "93efcd76e0b1c77d954a25614458c81d5b02c2b6ddf0c40e3c75a738fa4bf2ac",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686161741,
"kind": 1,
"tags": [
[
"e",
"77c824d861e497590991b7dc940a75787db11a7b2eab6adcf5563d0847a4df18",
"",
"root"
],
[
"e",
"9256b9dc8309c20e35e689335c4d593e5af094e349e7a2d4bc50f668cd81b969",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-12-12\n📝 Original message:On Wed, Dec 12, 2018 at 08:12:10PM +1030, Rusty Russell via bitcoin-dev wrote:\n\u003e Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e writes:\n\u003e \u003e Here is a combined proposal:\n\u003e \u003e * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,\n\u003e \u003e and SIGHASH_SCRIPTMASK.\n\u003e \u003e * A new opcode OP_MASK is added, which acts as a NOP during execution.\n\u003e \u003e * The sighash is computed like in BIP143, but:\n\u003e \u003e * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode\n\u003e \u003e the subsequent opcode/push is removed.\n\u003e I'm asking on-list because I'm sure I'm not the only confused one.\n\u003e Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always\n\u003e perform mask-removal for signing?\n\nThe way I'm thinking about it is there's four amounts of knowledge you\ncould have about the input you're spending at the time you generate a\nsignature:\n\n ALL: you know everything about every input for this tx\n\n SINGLE: you know everything about the input you're signing for, but\n not necessarily the others\n\n SCRIPTPUBKEY: you know the exact scriptPubKey you're trying to satisfy, but\n don't know the txid\n\n SCRIPTMASK: you don't know the txid, don't know the scriptPubKey, don't\n know the other taproot branches, and maybe don't even know the masked\n out terms in the script -- but you do know the structure of the\n script, and the non-masked terms\n\nThere's no value to masking in any but the final case -- the txid and\nscriptPubKey commit to the full scriptcode already, so also signing the\nscriptcode is just belt-and-suspenders protection.\n\n(It might be that the \"SCRIPTPUBKEY\" option isn't very useful in\npractice; maybe you'll always either know the txid, or need to mask\nsomething?)\n\n\u003e And I am struggling to understand the role of scriptmask in a taproot\n\u003e world, where the alternate script is both hidden and general?\n\nIn a taproot world, your scriptPubKey is a point P=Q+H(Q,S)*G, where S\nis a merkle root of possibly many scripts, and is spendable either by:\n\n sig(P)\n Q, path(S,script), script, witness(script)\n\nSCRIPTMASK lets you prepare a signature for one particular script in\nadvance, even before you've decided what the other scripts are (and even\nwhat the base point Q is), let alone built an actual transaction.\n\nAt least, that's my current understanding; and I think it makes sense...\n\nCheers,\naj",
"sig": "55f1c378db5027f60c1db7d28084d60772001b7955d84860a9b402fc2fdfafd1e05a9fd261fcee9ffa4bd8b9ada6d86ce1dfb07643f67a0c601a992cf3f22fa6"
}