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 155C6B6FA for ; Thu, 7 Mar 2019 10:44:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7035A2D4 for ; Thu, 7 Mar 2019 10:44:54 +0000 (UTC) Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 8ABAF38A0D77; Thu, 7 Mar 2019 10:44:36 +0000 (UTC) X-Hashcash: 1:25:190307:lf-lists@mattcorallo.com::IojZsoCtfK9ebLrW:Idqs X-Hashcash: 1:25:190307:bitcoin-dev@lists.linuxfoundation.org::z8CDbt4xeICqKgBQ:aNVTV From: Luke Dashjr To: Matt Corallo Date: Thu, 7 Mar 2019 10:44:34 +0000 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201903071044.34985.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED 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 14:29:56 +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 10:44:55 -0000 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. > * 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. > 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.) > * 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. > ** 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. Luke