"We can look at the adoption of the last major Bitcoin core release to guess how long it might take people to upgrade. 0.11.0 was released on 12 July, 2015. Twenty eight days later, about 38% of full nodes were running that release. Three months later, about 50% of the network was running that release, and six months later about 66% of the network was running some flavor of 0.11."

On what grounds do you think it is reasonable to assume that this update will roll out 6x faster than previous data suggested, as oppose to your own observation of 66% adoption in 6 month. or do you believe 38% node upgrade-coverage ( in 28 days ) on the network for a hard fork is good enough?

There are no harm in choosing a longer grace period but picking one short as 28 days you risk on alienating the nodes who do not upgrade with the aggressive upgrade timeline you proposed.



On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
This has been reviewed by merchants, miners and exchanges for a couple of weeks, and has been implemented and tested as part of the Bitcoin Classic and Bitcoin XT implementations.

Constructive feedback welcome; argument about whether or not it is a good idea to roll out a hard fork now will be unproductive, so I vote we don't go there.

Draft BIP:
  https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki

Summary:  
  Increase block size limit to 2,000,000 bytes.
  After 75% hashpower support then 28-day grace period.
  With accurate sigop counting, but existing sigop limit (20,000)
  And a new, high limit on signature hashing

Blog post walking through the code:
  http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork

Blog post on a couple of the constants chosen:

--
--
Gavin Andresen


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




--
Yifu Guo
"Life is an everlasting self-improvement."