From: Gavin Andresen <gavinandresen@gmail•com>
To: Jannes Faber <jannes.faber@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
Date: Fri, 29 Jan 2016 11:39:14 -0500 [thread overview]
Message-ID: <CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com> (raw)
In-Reply-To: <CABeL=0hLCt5OTj0KCg7Ci-gMbL7=MGvm9NhBCquWMObYkbgEuw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]
On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
>
> Question if you'll allow me. This is not about Gavin's latest hard fork
> proposal but in general about any hard (or soft) fork.
>
> I was surprised to see a period expressed in human time instead of in
> block time:
>
> > Blocks with timestamps greater than or equal to the triggering block's
> timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.
>
>
Block timestamps are in the 80-byte block header, so activation is
completely deterministic and can be determined from just the sequence of
block headers. There are no edge cases to worry about.
But even more so I would expect there to be significant differences in
> effects on non-updated clients depending on the moment (expressed as block
> number) of applying the new rules. I see a few options, all relating to the
> 2016 blocks recalibration window.
>
It doesn't matter much where in the difficulty period the fork happens; if
it happens in the middle, the lower-power fork's difficulty will adjust a
little quicker.
Example: (check my math, I'm really good at screwing up at basic
arithmetic):
Fork at block%2016: 25% hashpower will take 8 weeks to produce 2016
blocks, difficulty drops by 4.
Fork one-week (halfway) into difficulty period: 25% hashpower will take 4
weeks to adjust, difficulty drops by 5/2 = 2.5
It will then take another 3.2 weeks to get to the next difficult adjustment
period and normal 10-minute blocks.
That's an unrealisitic scenario, though-- there will not be 25% of hash
power on a minority fork. I wrote about why in a blog post today:
http://gavinandresen.ninja/minority-branches
If you assume a more realistic single-digit-percentage of hash power on the
minority fork, then the numbers get silly (e.g. two or three months of an
hour or three between blocks before a difficulty adjustment).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3013 bytes --]
next prev parent reply other threads:[~2016-01-29 16:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 2:31 Jannes Faber
2016-01-29 16:39 ` Gavin Andresen [this message]
2016-01-29 18:50 ` Jorge Timón
2016-01-29 19:11 ` Peter Todd
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=CABsx9T0oY2OuPCRgnQmqbLOBSQVd-yuQ8mMXjfzYpJTjXn8woQ@mail.gmail.com \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jannes.faber@gmail$(echo .)com \
/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