📅 Original date posted:2019-03-07
📝 Original message: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.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:16:53
in reply to nevent1q…r3pl
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 18:16:53Event JSON
{
"id": "bf6828b7af20594586428b9065ea221024590e33180053338c1640381570f6ca",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686161813,
"kind": 1,
"tags": [
[
"e",
"2143f249ef40bc25f11c5b0400632be46488d3edd45da9192505bf2da32bb977",
"",
"root"
],
[
"e",
"f4bdebd804e6bf8e620ae1cb0ea41bc56ac5d7ad64e07a2f7648a053d0e8fd27",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-03-07\n📝 Original message:I can't say I'm particularly married to this idea (hence the alternate \nproposal in the original email), but at the same time the lack of \nexisting transactions using these bits (and the redundancy thereof - \nthey don't *do* anything special) seems to be pretty strong indication \nthat they are not in use. One could argue a similarity between these \nbits and OP_NOPs - no one is going to create transactions that require \nOP_NOP execution to be valid as they are precisely the kind of thing \nthat may get soft-forked to have a new meaning. While the sighash bits \nare somewhat less candidates for soft-forking, I don't think \"someone \nmay have shoved random bits into parts of their \nlocked-for-more-than-a-year transactions\" is sufficient reason to not \nsoft-fork something out. Obviously, actually *seeing* it used in \npractice or trying to fork them out in a fast manner would be \nunacceptable, but neither is being proposed here.\n\nMatt\n\nOn 3/7/19 3:16 PM, Russell O'Connor wrote:\n\u003e \n\u003e * If the sighash type byte (ie last byte in a signature being evaluated\n\u003e during the execution of OP_CHECKSIG[VERIFY] or\n\u003e OP_CHECKMULTISIG[VERIFY])\n\u003e is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script\n\u003e execution fails. This does not apply to 0-length signature stack\n\u003e elements.\n\u003e \n\u003e \n\u003e The sighash type byte is a \"great\" place to store a few bits of \n\u003e ancillary data when making signatures. Okay it isn't great, but it is \n\u003e good enough that some misguided users may have been using it and have \n\u003e unbroadcast transactions in cold storage (think sweeps) for UTXOs whose \n\u003e private keys may have been lost. I don't think that one's hunch that \n\u003e there isn't much risk in disabling these sighashes is good enough to put \n\u003e people funds at risk, especially given the alternative proposal of \n\u003e caching the just-before-the-last-byte sighash midstate that is available.",
"sig": "1d4c8a639e87c4382d69c83cf77370d713df7e3082f7f0acd255a295584de1672b52270b3c82545b2ee62487ce8d2a224101a3883369e32e2db7c3cf284c62ab"
}