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 9682CE21 for ; Tue, 9 Feb 2016 22:00:47 +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 3592B1B5 for ; Tue, 9 Feb 2016 22:00:47 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 2CEA25CDA7; Tue, 9 Feb 2016 22:00:46 +0000 (UTC) To: Anthony Towns , Bitcoin Dev References: <56B8EBF8.4050602@mattcorallo.com> <20160209090002.GB18324@sapphire.erisian.com.au> <56BA5FF9.6090905@mattcorallo.com> From: Matt Corallo Message-ID: <56BA618C.4010301@mattcorallo.com> Date: Tue, 9 Feb 2016 22:00:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56BA5FF9.6090905@mattcorallo.com> Content-Type: text/plain; charset=windows-1252 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: Tue, 09 Feb 2016 22:04:51 +0000 Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2016 22:00:47 -0000 Oops, forgot to reply to your last point. Indeed, we could push for more place by just always having one 0-byte, but I'm not sure the added complexity helps anything? ASICs can never be designed which use more extra-nonce-space than what they can reasonably assume will always be available, so we might as well just set the maximum number of bytes and let ASIC designers know exactly what they have available. Currently blocks start with at least 8 0-bytes. We could just say minimum difficulty is now 6 0-bytes (2**16x harder) and reserve those? Anyway, someone needs to take a closer look at the midstate optimization stuff to see what is reasonable required. Matt >>> 4) Instead of requiring the first four bytes of the previous block hash >>> field be 0s, we allow them to contain any value. This allows Bitcoin >>> mining hardware to reduce the required logic, making it easier to >>> produce competitive hardware [1]. >>> [1] Simpler here may not be entirely true. There is potential for >>> optimization if you brute force the SHA256 midstate, but if nothing >>> else, this will prevent there being a strong incentive to use the >>> version field as nonce space. This may need more investigation, as we >>> may wish to just set the minimum difficulty higher so that we can add >>> more than 4 nonce-bytes. >> >> Could you just use leading non-zero bytes of the prevhash as additional >> nonce? >> >> So to work out the actual prev hash, set leading bytes to zero until >> you hit a zero. Conversely, to add nonce info to a hash, if there are >> N leading zero bytes, fill up the first N-1 (or less) of them with >> non-zero values. >> >> That would give a little more than 255**(N-1) possible values >> ((255**N-1)/254) to be exact). That would actually scale automatically >> with difficulty, and seems easy enough to make use of in an ASIC?