public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
Cc: Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Date: Tue, 9 Feb 2016 22:39:34 +0000	[thread overview]
Message-ID: <56BA6AA6.5060907@mattcorallo.com> (raw)
In-Reply-To: <201602092210.45265.luke@dashjr.org>



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.


  reply	other threads:[~2016-02-09 22:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-08 19:26 [bitcoin-dev] On Hardforks in the Context of SegWit 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
2016-02-09 22:10       ` Luke Dashjr
2016-02-09 22:39         ` Matt Corallo [this message]
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=56BA6AA6.5060907@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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