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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
