From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 781C2C7B7 for ; Thu, 7 Mar 2019 19:44:26 +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 C94323F7 for ; Thu, 7 Mar 2019 19:44:25 +0000 (UTC) Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id B309F12035A; Thu, 7 Mar 2019 19:44:23 +0000 (UTC) To: Luke Dashjr References: <201903071044.34985.luke@dashjr.org> From: Matt Corallo Message-ID: <73b04e70-33aa-076c-a3a5-a658a01876c5@mattcorallo.com> Date: Thu, 7 Mar 2019 19:44:23 +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: <201903071044.34985.luke@dashjr.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] 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:44:26 -0000 Replies inline. On 3/7/19 10:44 AM, Luke Dashjr wrote: > On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote: >> I'd like to ask the BIP editor to assign a BIP number. > > Needs a Backward Compatibility section, and should have a bips repo PR opened > after discussion on the ML. Oops, I guess most of the "Discussion" section can just be moved into a "Backwards Compatibility" section. Will do before PR'ing. >> * The 4th change (making non-standard signature hash types invalid) >> may be worth discussing. In order to limit the number of potential >> signature hashes which could be used per-input (allowing us to cache >> them to avoid re-calculation), we can disable non-standard sighash >> types. Alternatively, however, most of the same effect could be achieved >> by caching the just-before-the-last-byte sighash midstate and hashing >> only the last byte when a checking signatures. Still, them having been >> non-standard for many years makes me doubt there is much risk involved >> in disabling them, and I don't see much potential use-case for keeping >> them around so I'd like to just remove them. > > I don't understand what is being removed here. This refers to the following spec change: 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. >> As for why the timewarp vulnerability should (IMO rather obviously) be >> fixed, it seems rather clear that the only potential use for exploiting >> it would be either to inflate the currency supply maliciously by miners >> or to fork in what amounts to extension blocks. As for why extension >> blocks are almost certainly not the right approach to such changes, its >> likely worth reading this old post: >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510 >> .html > > While I agree that extension blocks are typically a bad choice, I'm not sure > the argument really applies to forward blocks. (That being said, I find > forward blocks overcomplicated and probably not a reason to avoid this.) I agree they are somewhat separate ideas, but the arguments in that thread apply equally to timewarp-based inter-block-time reductions. If you want to discuss it further, I'd suggest a new thread. >> * Transactions smaller than 65 bytes when serialized without witness >> data are invalid. > > Rationale should include the reason(s) why the size doesn't count the witness > here. Will add. >> ** Note that miners today only enforce increasing timestamps against the >> median-timestamp-of-last-11-blocks, so miners who do not upgrade may >> mine a block which violates this rule at the beginning of a difficulty >> window if the last block in a difficulty window has a timestamp in the >> future. Thus, it is strongly recommended that SPV clients enforce the >> new nTime rules to avoid following any potential forks which occur. > > This should probably be moved outside Discussion. (Perhaps to the missing > Backward Compatibility section?) > >> * There are several early-stage proposals which may affect the execution >> of scripts, including proposals such as Schnorr signatures, Taproot, >> Graftroot, and MAST. These proposals are not expected to have any >> interaction with the changes in this BIP, as they are likely to only >> apply to SegWit scripts, which are not covered by any of the new rules >> except for the sighash type byte rule. Thus, the sighash type byte rule >> defined above only applies to *current* signature-checking opcodes, as >> any new signature-checking is likely to be implemented via the >> introduction of new opcodes. > > It's not clear that new opcodes will necessarily always be used. Probably > would be good to clarify the "non-Segwit or witness v0 only" rule in the > Specification section. Note that you inherently have to use a new opcode for such things - the non-standard type bytes *are* defined and define a sighash/signature, they can't be simply redefined to a new sighash/signature type in a soft fork.