Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-01 📝 Original message: On Mon, Sep 30, 2019 at ...
📅 Original date posted:2019-10-01
📝 Original message:
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)
Cheers,
aj
📝 Original message:
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)
Cheers,
aj