From: Anthony Towns <aj@erisian.com.au>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Mon, 8 Feb 2016 01:19:27 +1000 [thread overview]
Message-ID: <20160207151927.GA14750@sapphire.erisian.com.au> (raw)
In-Reply-To: <CABsx9T0N_TBbmy3xr-mqNDdKVF_3_QHYA1W2ttsZBQnt4dWxgw@mail.gmail.com>
On Sun, Feb 07, 2016 at 09:16:02AM -0500, Gavin Andresen via bitcoin-dev wrote:
> There will be approximately zero percentage of hash power left on the
> weaker branch of the fork, based on past soft-fork adoption by miners (they
> upgrade VERY quickly from 75% to over 95%).
The stated reasoning for 75% versus 95% is "because it gives "veto power"
to a single big solo miner or mining pool". But if a 20% miner wants to
"veto" the upgrade, with a 75% threshold, they could instead simply use
their hashpower to vote for an upgrade, but then not mine anything on
the new chain. At that point there'd be as little as 55% mining the new
2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
minute blocks versus 22 minute blocks, which doesn't seem like much of
a difference in practice, and at that point hashpower could plausibly
end up switching almost entirely back to the original consensus rules
prior to the grace period ending.
With a non-consensus fork, I think you need to expect people involved to
potentially act in ways that aren't very gentlemanly, and guard against
it if you want the fork to be anything other than a huge mess.
Cheers,
aj
next prev parent reply other threads:[~2016-02-07 15:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09 ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06 0:12 ` Luke Dashjr
2016-02-06 3:14 ` Jorge Timón
2016-02-06 15:37 ` Gavin Andresen
2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd
2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
2016-02-06 21:28 ` David Thomson
2016-02-07 18:49 ` Chris Priest
2016-02-06 17:09 ` Jorge Timón
2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
2016-02-07 16:54 ` Peter Todd
2016-02-07 15:19 ` Anthony Towns [this message]
2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 17:24 ` jl2012
2016-02-07 17:56 ` Jonathan Toomim
2016-02-07 21:01 ` Luke Dashjr
2016-02-07 21:33 ` Steven Pine
2016-02-07 22:04 ` Corey Haddad
2016-02-07 22:25 ` Steven Pine
2016-02-06 20:36 ` Luke Dashjr
2016-02-06 22:22 ` Peter Todd
2016-02-07 5:21 ` Jannes Faber
2016-02-07 18:55 ` Jonathan Toomim
2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan
2016-02-09 13:59 ` Yifu Guo
2016-02-09 16:54 ` Gavin Andresen
2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns
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=20160207151927.GA14750@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