ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2019-10-01 š Original message:Good morning lists, Let me ...
š
Original date posted:2019-10-01
š Original message:Good morning lists,
Let me propose the below radical idea:
* `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with:
* 1 RETURN
* higher-`nSequence` replacement
* DER-encoded pubkeys
* unrestricted `scriptPubKey`
* Payee-security-paid-by-payer (i.e. lack of P2SH)
* `OP_CAT` and `OP_MULT` and `OP_ADD` and friends
* transaction malleability
* probably many more
So let me propose the more radical excision, starting with SegWit v1:
* Remove `SIGHASH` from signatures.
* Put `SIGHASH` on public keys.
Public keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate).
`OP_CHECKSIG` and friends then look at the *public key* to determine sighash algorithm rather than the signature.
As we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`.
However, we can then utilize the many many ways to hide public keys away until they are needed, exemplified in MAST-inside-Taproot.
I propose also the addition of the opcode:
<sighash> <pubkey> OP_SETPUBKEYSIGHASH
* `sighash` must be one byte.
* `pubkey` may be the special byte `0x1`, meaning "just use the Taproot internal pubkey".
* `pubkey` may be 33-byte public key, in which case the `sighash` byte is just prepended to it.
* `pubkey` may be 34-byte public key with sighash, in which case the first byte is replaced with `sighash` byte.
* If `sighash` is `0x00` then the result is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.
This retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment.
This is done by using the script:
<pubkey> OP_SETPUBKEYSIGHASH OP_CHECKSIG
Then the sighash can be put in the witness stack after the signature, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so.
This is malleability-safe as the signature still commits to the `SIGHASH` it was created for.
However, by default, public keys will not have an attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).
This removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed.
Would this not be a superior solution?
Regards,
ZmnSCPxj
Published at
2023-06-07 18:20:47Event JSON
{
"id": "c47f1ccbb0310832547176d646a19b5125ef213ec2493ade272877af8b7b734c",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686162047,
"kind": 1,
"tags": [
[
"e",
"d4024562676a2b9f9ecb0fbb42db7e27569a53d33c57a608de3e3625f31c1f56",
"",
"root"
],
[
"e",
"56b15cf884b9ab0bd88bdbf011da12009af6c5a5dd3679cbf68c9c69ec09a70c",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2019-10-01\nš Original message:Good morning lists,\n\nLet me propose the below radical idea:\n\n* `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with:\n * 1 RETURN\n * higher-`nSequence` replacement\n * DER-encoded pubkeys\n * unrestricted `scriptPubKey`\n * Payee-security-paid-by-payer (i.e. lack of P2SH)\n * `OP_CAT` and `OP_MULT` and `OP_ADD` and friends\n * transaction malleability\n * probably many more\n\nSo let me propose the more radical excision, starting with SegWit v1:\n\n* Remove `SIGHASH` from signatures.\n* Put `SIGHASH` on public keys.\n\nPublic keys are now encoded as either 33-bytes (implicit `SIGHASH_ALL`) or 34-bytes (`SIGHASH` byte, followed by pubkey type, followed by pubkey coordinate).\n`OP_CHECKSIG` and friends then look at the *public key* to determine sighash algorithm rather than the signature.\n\nAs we expect public keys to be indirectly committed to on every output `scriptPubKey`, this is automatically output tagging to allow particular `SIGHASH`.\nHowever, we can then utilize the many many ways to hide public keys away until they are needed, exemplified in MAST-inside-Taproot.\n\nI propose also the addition of the opcode:\n\n \u003csighash\u003e \u003cpubkey\u003e OP_SETPUBKEYSIGHASH\n\n* `sighash` must be one byte.\n* `pubkey` may be the special byte `0x1`, meaning \"just use the Taproot internal pubkey\".\n* `pubkey` may be 33-byte public key, in which case the `sighash` byte is just prepended to it.\n* `pubkey` may be 34-byte public key with sighash, in which case the first byte is replaced with `sighash` byte.\n* If `sighash` is `0x00` then the result is a 33-byte public key (the sighash byte is removed) i.e. `SIGHASH_ALL` implicit.\n\nThis retains the old feature where the sighash is selected at time-of-spending rather than time-of-payment.\nThis is done by using the script:\n\n \u003cpubkey\u003e OP_SETPUBKEYSIGHASH OP_CHECKSIG\n\nThen the sighash can be put in the witness stack after the signature, letting the `SIGHASH` flag be selected at time-of-signing, but only if the SCRIPT specifically is formed to do so.\nThis is malleability-safe as the signature still commits to the `SIGHASH` it was created for.\n\nHowever, by default, public keys will not have an attached `SIGHASH` byte, implying `SIGHASH_ALL` (and disallowing-by-default non-`SIGHASH_ALL`).\n\nThis removes the problems with `SIGHASH_NONE` `SIGHASH_SINGLE`, as they are allowed only if the output specifically says they are allowed.\n\nWould this not be a superior solution?\n\nRegards,\nZmnSCPxj",
"sig": "ee889caced98085848525c1a83fe17c5bf063d70384ef316f6f0d2bf731e7cf1fe6a3b3c5d768b97f437cafb5ee80f99ee00b96033750bc03981719b18b1bd02"
}