📅 Original date posted:2019-10-01
📝 Original message:
Good morning aj,
> On Mon, Sep 30, 2019 at 11:28:43PM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`.
>
> I don't think there's any meaningful difference between making a new
> opcode and making a new tapscript public key type; the difference is
> just one of encoding:
>
> 3301<key>AC [CHECKSIG of public key type 0x01]
> 32<key>B3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key]
>
> > This new opcode ignores any `SIGHASH` flags, if present, on a signature,
>
> (How sighash flags are treated can be redefined by new public key types;
> if that's not obvious already)
Thank you for this thought,
I believe under tapscript v0 we can give `OP_1` as the public key to `OP_CHECKSIG` to mean to reuse the internal Taproot pubkey, would it be possible to have some similar mechanism here, to copy the internal Taproot pubkey but also to enable new `SIGHASH` flag for this particular script only?
This seems fine, as then a Decker-Russell-Osuntokun funding tx output between nodes A, B, and C would have:
* Taproot internal key: `P = MuSig(A, B, C)`
* Script 1: leaf version 0, `<MuSig(A,B,C) + pubkeytype 1> OP_CHECKSIG`
Then, update transactions could use `MuSig(A,B,C)` for signing along the "update" path, with unique "state" keys.
And cooperative closes would sign using `P + h(P | MAST(<MuSig(A,B,C) + pubkeytype 1> OPCHECKSIG)) * G`, not revealing the fact that this was in fact a Decker-Russell-Osuntokun output.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:56:21
in reply to nevent1q…paeu
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:56:21Event JSON
{
"id": "e36a1c9ffeaccd2aa5dcd6bf1197e9086e968dd4bae3e0de513b6208f1fb3178",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315381,
"kind": 1,
"tags": [
[
"e",
"cdcb20d8f8d63cc4e462299d7b2042087b535b172c963061dbb6929331fffa55",
"",
"root"
],
[
"e",
"b495eec5b883405de2c18eb172e4086e5a460b7a518067fb09cb4292d5d45c5e",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2019-10-01\n📝 Original message:\nGood morning aj,\n\n\n\u003e On Mon, Sep 30, 2019 at 11:28:43PM +0000, ZmnSCPxj via bitcoin-dev wrote:\n\u003e\n\u003e \u003e Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`.\n\u003e\n\u003e I don't think there's any meaningful difference between making a new\n\u003e opcode and making a new tapscript public key type; the difference is\n\u003e just one of encoding:\n\u003e\n\u003e 3301\u003ckey\u003eAC [CHECKSIG of public key type 0x01]\n\u003e 32\u003ckey\u003eB3 [CHECKSIG_WITHOUT_INPUT (replacing NOP4) of key]\n\u003e\n\u003e \u003e This new opcode ignores any `SIGHASH` flags, if present, on a signature,\n\u003e\n\u003e (How sighash flags are treated can be redefined by new public key types;\n\u003e if that's not obvious already)\n\n\nThank you for this thought,\nI believe under tapscript v0 we can give `OP_1` as the public key to `OP_CHECKSIG` to mean to reuse the internal Taproot pubkey, would it be possible to have some similar mechanism here, to copy the internal Taproot pubkey but also to enable new `SIGHASH` flag for this particular script only?\n\nThis seems fine, as then a Decker-Russell-Osuntokun funding tx output between nodes A, B, and C would have:\n\n* Taproot internal key: `P = MuSig(A, B, C)`\n* Script 1: leaf version 0, `\u003cMuSig(A,B,C) + pubkeytype 1\u003e OP_CHECKSIG`\n\nThen, update transactions could use `MuSig(A,B,C)` for signing along the \"update\" path, with unique \"state\" keys.\nAnd cooperative closes would sign using `P + h(P | MAST(\u003cMuSig(A,B,C) + pubkeytype 1\u003e OPCHECKSIG)) * G`, not revealing the fact that this was in fact a Decker-Russell-Osuntokun output.\n\nRegards,\nZmnSCPxj",
"sig": "f4d9390eaebeb06e811b329710198f0edd1b79c613f637a77e8f01b32645a0d1c0ef1d2aa818e1be46529c11d67825272dc9e1125cea63dc5db2619b91a164b9"
}