To: Anthony Towns <aj@erisian.com.au>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <56B8EBF8.4050602@mattcorallo.com>
	<20160209090002.GB18324@sapphire.erisian.com.au>
	<56BA5FF9.6090905@mattcorallo.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
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
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Precedence: list

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?