Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B2B2DC7A9 for ; Thu, 7 Mar 2019 19:57:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 56EC55E2 for ; Thu, 7 Mar 2019 19:57:31 +0000 (UTC) Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 0316112035A; Thu, 7 Mar 2019 19:57:29 +0000 (UTC) To: Russell O'Connor , Bitcoin Protocol Discussion References: From: Matt Corallo Message-ID: 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Mar 2019 23:48:02 +0000 Subject: Re: [bitcoin-dev] Sighash Type Byte; Re: BIP Proposal: The Great Consensus Cleanup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:57:31 -0000 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.