📅 Original date posted:2018-12-12
📝 Original message:Johnson Lau <jl2012 at xbt.hk> writes:
>> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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.
>>
>> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
>> perform mask-removal for signing?
>
> Because a hardware wallet may want to know what exact script it is signing?
OK, removing OP_MASKs unconditionally would introduce a hole without
some explicit flag to say they've been removed (the "real script" could
be something different with OP_MASKs). We could have the signature
commit to the outputscript, but that's a bit meh.
> Masked script has reduced security, but this is a tradeoff with
> functionality (e.g. eltoo can’t work without masking part of the
> script). So when you don’t need that extra functionality, you go back
> to better security
>
> However, I’m not sure if there is any useful NOINPUT case with unmasked script.
This is *not* true of Eltoo; the script itself need not change for the
rebinding (Christian, did something change?).
So, can we find an example where OP_MASK is useful?
>> If you're signing arbitrary scripts, you're surely in trouble already?
>>
>> And I am struggling to understand the role of scriptmask in a taproot
>> world, where the alternate script is both hidden and general?
>
> It makes sure that your signature is applicable to a specific script branch, not others (assuming you use the same pubkey in many branches, which is avoidable)
If I'm using SIGHASH_NOINPUT, I'm already required to take care with key
reuse.
Without a concrete taproot proposal it's hard to make assertions, but
if the signature flags that it's using the taproot script, it's
no less safe, and more general AFAICT.
Thanks!
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 18:15:36
in reply to nevent1q…g9eq
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 18:15:36Event JSON
{
"id": "16738b5ac8ffcfe1c3aa82e65735df8af40f10efa8b1a68dab55904f0b82eef2",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686161736,
"kind": 1,
"tags": [
[
"e",
"77c824d861e497590991b7dc940a75787db11a7b2eab6adcf5563d0847a4df18",
"",
"root"
],
[
"e",
"53c97a573f670f8ac2dea4a3cecc114d752c73a91fa310f0ba699b67f9a8007e",
"",
"reply"
],
[
"p",
"492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7"
]
],
"content": "📅 Original date posted:2018-12-12\n📝 Original message:Johnson Lau \u003cjl2012 at xbt.hk\u003e writes:\n\u003e\u003e On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e\u003e Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e writes:\n\u003e\u003e\u003e Here is a combined proposal:\n\u003e\u003e\u003e * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,\n\u003e\u003e\u003e and SIGHASH_SCRIPTMASK.\n\u003e\u003e\u003e * A new opcode OP_MASK is added, which acts as a NOP during execution.\n\u003e\u003e\u003e * The sighash is computed like in BIP143, but:\n\u003e\u003e\u003e * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode\n\u003e\u003e\u003e the subsequent opcode/push is removed.\n\u003e\u003e \n\u003e\u003e Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always\n\u003e\u003e perform mask-removal for signing?\n\u003e\n\u003e Because a hardware wallet may want to know what exact script it is signing?\n\nOK, removing OP_MASKs unconditionally would introduce a hole without\nsome explicit flag to say they've been removed (the \"real script\" could\nbe something different with OP_MASKs). We could have the signature\ncommit to the outputscript, but that's a bit meh.\n\n\u003e Masked script has reduced security, but this is a tradeoff with\n\u003e functionality (e.g. eltoo can’t work without masking part of the\n\u003e script). So when you don’t need that extra functionality, you go back\n\u003e to better security\n\u003e\n\u003e However, I’m not sure if there is any useful NOINPUT case with unmasked script.\n\nThis is *not* true of Eltoo; the script itself need not change for the\nrebinding (Christian, did something change?).\n\nSo, can we find an example where OP_MASK is useful?\n\n\u003e\u003e If you're signing arbitrary scripts, you're surely in trouble already?\n\u003e\u003e \n\u003e\u003e And I am struggling to understand the role of scriptmask in a taproot\n\u003e\u003e world, where the alternate script is both hidden and general?\n\u003e\n\u003e It makes sure that your signature is applicable to a specific script branch, not others (assuming you use the same pubkey in many branches, which is avoidable)\n\nIf I'm using SIGHASH_NOINPUT, I'm already required to take care with key\nreuse.\n\nWithout a concrete taproot proposal it's hard to make assertions, but\nif the signature flags that it's using the taproot script, it's\nno less safe, and more general AFAICT.\n\nThanks!\nRusty.",
"sig": "b6f89804da7b97a150b30c27cd748451e3a20d639b6b11b6d8422788a1939d8e3814f0057ea0e999daece61c4e6c75a129543625bfd6de47a60f95817117b00e"
}