I can't say I'm particularly married to this idea (hence the alternate
proposal in the original email), but at the same time the lack of
existing transactions using these bits (and the redundancy thereof -
they don't *do* anything special) seems to be pretty strong indication
that they are not in use. One could argue a similarity between these
bits and OP_NOPs - no one is going to create transactions that require
OP_NOP execution to be valid as they are precisely the kind of thing
that may get soft-forked to have a new meaning. While the sighash bits
are somewhat less candidates for soft-forking, I don't think "someone
may have shoved random bits into parts of their
locked-for-more-than-a-year transactions" is sufficient reason to not
soft-fork something out. Obviously, actually *seeing* it used in
practice or trying to fork them out in a fast manner would be
unacceptable, but neither is being proposed here.
Matt
On 3/7/19 3:16 PM, Russell O'Connor wrote:
* If the sighash type byte (ie last byte in a signature being evaluated
during the execution of OP_CHECKSIG[VERIFY] or
OP_CHECKMULTISIG[VERIFY])
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
execution fails. This does not apply to 0-length signature stack
elements.
The sighash type byte is a "great" place to store a few bits of
ancillary data when making signatures. Okay it isn't great, but it is
good enough that some misguided users may have been using it and have
unbroadcast transactions in cold storage (think sweeps) for UTXOs whose
private keys may have been lost. I don't think that one's hunch that
there isn't much risk in disabling these sighashes is good enough to put
people funds at risk, especially given the alternative proposal of
caching the just-before-the-last-byte sighash midstate that is available.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
