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 137DFDC9 for ; Tue, 9 Feb 2016 22:39:38 +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 A8C94189 for ; Tue, 9 Feb 2016 22:39:37 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id F3F875CD3F; Tue, 9 Feb 2016 22:39:35 +0000 (UTC) To: Luke Dashjr , bitcoin-dev@lists.linuxfoundation.org References: <56B8EBF8.4050602@mattcorallo.com> <56BA5FF9.6090905@mattcorallo.com> <56BA618C.4010301@mattcorallo.com> <201602092210.45265.luke@dashjr.org> From: Matt Corallo Message-ID: <56BA6AA6.5060907@mattcorallo.com> Date: Tue, 9 Feb 2016 22:39:34 +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: <201602092210.45265.luke@dashjr.org> 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:58:46 +0000 Cc: Anthony Towns 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:39:38 -0000 On 02/09/16 22:10, Luke Dashjr wrote: > On Tuesday, February 09, 2016 10:00:44 PM Matt Corallo via bitcoin-dev wrote: >> 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? > > The extranonce rolling doesn't necessarily need to happen in the ASIC itself. > With the current extranonce-in-gentx, an old RasPi 1 can only handle creating > work for up to 5 Gh/s with a 500k gentx. Did you read the footnote on my original email? There is some potential for optimization if you can brute-force the midstate, which today requires using the nVersion space as nonce. In order to fix this we need to add nonce space in the first compression function, so this is an ideal place. Even ignoring that reducing complexity of mining control stuff is really nice. If we could go back to just providing block headers to miners instead of having to provide the entire transaction-hash-list we could move a ton of complexity back into Bitcoin Core from mining setups, which have historically been pretty poorly-reviewed codebases. > Furthermore, there is a direct correlation between ASIC speeds and difficulty, > so increasing the extranonce space dynamically makes a lot of sense. > > I don't see any reason *not* to increase the minimum difficulty at the same > time, though. Meh, my point was less that its a really bad idea and more that it adds compexity that I dont see much need for.