public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] On Hardforks in the Context of SegWit
Date: Wed, 10 Feb 2016 15:16:56 +1000	[thread overview]
Message-ID: <20160210051655.GA1568@sapphire.erisian.com.au> (raw)
In-Reply-To: <56BA618C.4010301@mattcorallo.com>

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 ..."


  parent reply	other threads:[~2016-02-10  5:17 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
2016-02-10  5:16       ` Anthony Towns [this message]
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=20160210051655.GA1568@sapphire.erisian.com.au \
    --to=aj@erisian.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.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