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 67EDFF38 for ; Wed, 10 Feb 2016 05:17:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BF468F3 for ; Wed, 10 Feb 2016 05:17:04 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) id 1aTN9A-0001ZE-4s; Wed, 10 Feb 2016 15:17:02 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 10 Feb 2016 15:16:56 +1000 Date: Wed, 10 Feb 2016 15:16:56 +1000 From: Anthony Towns To: Bitcoin Dev Message-ID: <20160210051655.GA1568@sapphire.erisian.com.au> References: <56B8EBF8.4050602@mattcorallo.com> <20160209090002.GB18324@sapphire.erisian.com.au> <56BA5FF9.6090905@mattcorallo.com> <56BA618C.4010301@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BA618C.4010301@mattcorallo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Wed, 10 Feb 2016 05:17:05 -0000 On Tue, Feb 09, 2016 at 10:00:44PM +0000, Matt Corallo 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, I was thinking ASICs could be passed a mask of which bytes they could use for nonce; in which case the variable-ness can just be handled prior to passing the work to the ASIC. But on second thoughts, the block already specifies the target difficulty, so maybe that could be used to indicate which bytes of the previous hash must be zero? You have to be a bit careful to deal with the possibility that you just did a maximum difficulty increase compared to the previous block (in which case there may be fewer bits in the previous hash that are zero), but that's just a factor of 4, so: #define RETARGET_THRESHOLD ((1ul<<24) / 4) y = 32 - bits[0]; if (bits[1]*65536 + bits[2]*256 + bits[3] >= RETARGET_THRESHOLD) y -= 1; memset(prevhash, 0x00, y); // clear "first" y bytes of prevhash should work correctly/safely, and give you 8 bytes of additional nonce to play with at current difficulty (or 3 bytes at minimum difficulty), and scale as difficulty increases. No need to worry about avoiding zeroes that way either. As far as midstate optimisations go, rearranging the block to be: version ; time ; bits ; merkleroot ; prevblock ; nonce would mean that the last 12 bytes of prevblock and the 4 bytes of nonce would be available for manipulation [0] if the first round of sha256 was pre-calculated prior to being sent to ASICs (and also that version and time wouldn't be available). Worth considering? I don't see how you'd make either of these changes compatible with Luke-Jr's soft-hardfork approach [1] to ensuring non-upgraded clients/nodes can't be tricked into following a shorter chain, though. I think the approach I suggested in my mail avoid Gavin's proposed hard fork might work though [2]. Combining these with making merge-mining easier [1] and Luke-Jr/Peter Todd's ideas [3] about splitting the proof of work between something visible to miners, and something only visible to pool operators to avoid the block withholding attack on pooled mining would probably make sense though, to reduce the number of hard forks visible to lightweight clients? Cheers, aj [0] Giving a total of 128 bits, or 96 bits with difficulty such that only the last 8 bytes of prevblock are available. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.html [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012046.html [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012384.html In particular, the paragraph beginning "Alternatively, if the old blockchain has 10% of less hashpower ..."