📅 Original date posted:2019-10-01
📝 Original message:
ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
> To elucidate further ---
>
> Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,
> `OP_CHECKSIG_WITHOUT_INPUT`.
>
> This new opcode ignores any `SIGHASH` flags, if present, on a
> signature, but instead hashes the current transaction without the
> input references, then checks that hash to the signature.
>
> This is equivalent to `SIGHASH_NOINPUT`.
>
> Yet as an opcode, it would be possible to embed in a Taproot script.
>
> For example, a Decker-Russell-Osuntokun would have an internal Taproot
> point be a 2-of-2, then have a script `OP_1
> OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden
> script, but cooperative closes would use the 2-of-2 directly.
>
> Of note, is that any special SCRIPT would already be supportable by Taproot.
> This includes SCRIPTs that may potentially lose funds for the user.
> Yet such SCRIPTs are already targetable by a Taproot address.
>
> If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not
> so concerned about Taproot abuse?
That would certainly be another possibility, which I have not explored
in detail so far. Due to the similarity between the various signature
checking op-codes it felt that it should be a sighash flag, and it
neatly slotted into the already existing flags. If we go for a separate
opcode we might end up reinventing the wheel, and to be honest I feared
that proposing a new opcode would get us into bikeshedding territory
(which I apparently failed to avoid with the sighash flag anyway...).
The advantage would be that with the sighash flag the spender is in
charge of specifying the flags, whereas with an opcode the output
dictates the signature verification modalities. The downside is the
increased design space.
What do others think? Would this be an acceptable opt-in mechanism that
addresses the main concerns?
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:56:20
in reply to nevent1q…29l0
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:56:20Event JSON
{
"id": "81efa3f9779d63155745bb194242152eaf59305366d356f7d3a0c4a0f36cca01",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315380,
"kind": 1,
"tags": [
[
"e",
"cdcb20d8f8d63cc4e462299d7b2042087b535b172c963061dbb6929331fffa55",
"",
"root"
],
[
"e",
"688d9a6e4f389b34db66b7d81ff0694ad27218443c936a9e1038af81766b2955",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2019-10-01\n📝 Original message:\nZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e writes:\n\u003e To elucidate further ---\n\u003e\n\u003e Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode,\n\u003e `OP_CHECKSIG_WITHOUT_INPUT`.\n\u003e\n\u003e This new opcode ignores any `SIGHASH` flags, if present, on a\n\u003e signature, but instead hashes the current transaction without the\n\u003e input references, then checks that hash to the signature.\n\u003e\n\u003e This is equivalent to `SIGHASH_NOINPUT`.\n\u003e\n\u003e Yet as an opcode, it would be possible to embed in a Taproot script.\n\u003e\n\u003e For example, a Decker-Russell-Osuntokun would have an internal Taproot\n\u003e point be a 2-of-2, then have a script `OP_1\n\u003e OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden\n\u003e script, but cooperative closes would use the 2-of-2 directly.\n\u003e\n\u003e Of note, is that any special SCRIPT would already be supportable by Taproot.\n\u003e This includes SCRIPTs that may potentially lose funds for the user.\n\u003e Yet such SCRIPTs are already targetable by a Taproot address.\n\u003e\n\u003e If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not\n\u003e so concerned about Taproot abuse?\n\nThat would certainly be another possibility, which I have not explored\nin detail so far. Due to the similarity between the various signature\nchecking op-codes it felt that it should be a sighash flag, and it\nneatly slotted into the already existing flags. If we go for a separate\nopcode we might end up reinventing the wheel, and to be honest I feared\nthat proposing a new opcode would get us into bikeshedding territory\n(which I apparently failed to avoid with the sighash flag anyway...).\n\nThe advantage would be that with the sighash flag the spender is in\ncharge of specifying the flags, whereas with an opcode the output\ndictates the signature verification modalities. The downside is the\nincreased design space.\n\nWhat do others think? Would this be an acceptable opt-in mechanism that\naddresses the main concerns?\n\nCheers,\nChristian",
"sig": "d1af71522c55c3cd52bfa68c5dd884d3bbad97ccd96a01052c3d788f849c51e964e03d4f02f50f9e99bf4ff55b3b94b288cca8cee76bc0211840e4bf9425081a"
}