To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <eba5e3d0-de54-bf64-bf1a-24974a932d22@mattcorallo.com>
Date: Thu, 7 Mar 2019 19:57:29 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Sighash Type Byte;
	Re: BIP Proposal: The Great Consensus Cleanup
Precedence: list

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.