From: Matt Corallo <lf-lists@mattcorallo•com>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Date: Tue, 9 Feb 2016 22:00:44 +0000 [thread overview]
Message-ID: <56BA618C.4010301@mattcorallo.com> (raw)
In-Reply-To: <56BA5FF9.6090905@mattcorallo.com>
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?
next prev parent reply other threads:[~2016-02-09 22:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-08 19:26 Matt Corallo
2016-02-08 20:37 ` jl2012
2016-02-08 22:24 ` Tao Effect
[not found] ` <CAAcC9yuJY3Lsd7Z0rx8TFLNT1fJLhrpxzKJREQ7FmdNNjdXJow@mail.gmail.com>
2016-02-09 2:45 ` Tao Effect
2016-02-08 22:36 ` Simon Liu
2016-02-08 22:54 ` Peter Todd
2016-02-09 9:00 ` Anthony Towns
2016-02-09 21:54 ` Matt Corallo
2016-02-09 22:00 ` Matt Corallo [this message]
2016-02-09 22:10 ` Luke Dashjr
2016-02-09 22:39 ` Matt Corallo
2016-02-10 5:16 ` Anthony Towns
2016-02-09 12:32 Nicolas Dorier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56BA618C.4010301@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox