We don't have any evidence of how fast nodes will upgrade when faced with an impending hard fork, but it seems like a very safe assumption that the upgrade pace will be significantly faster.  The hard fork case it is: "upgrade or be kicked off the network".  In the previous cases it has been, "here's the latest and greatest, give it a go!".  Also, there will be alerts sent out warning people of the situation, prompting them to take action.

It is unclear if this will translate into more or less than 6x the adoption speed of previous instances, but the idea that it would be faster is solid.  28 days is aggressive, but again, it is only 28 days from when the fork triggers.  Compatible software is already available for anyone who wants to prepare.

It is also of significance that this proposed fork, and this debate, has been going on for many, many months.  If someone proposed a forking concept today, wrote the BIP tomorrow, deployed it next week, miners adopted it instantly, and 28 days later it was the flag day, those 28 days would be in a different context.  There is no surprise here.

On Sun, Feb 7, 2016 at 1:33 PM, Steven Pine via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Is it me or did Gavin ignore Yifu's direct questions? In case you missed it Gavin --

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

When Gavin writes "Responding to "28 days is not long enough" :

I keep seeing this claim made with no evidence to back it up.  As I said, I surveyed several of the biggest infrastructure providers and the btcd lead developer and they all agree "28 days is plenty of time."

For individuals... why would it take somebody longer than 28 days to either download and restart their bitcoind, or to patch and then re-run (the patch can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?"

~~

Isn't Yifu's comment, evidence, the very best sort of evidence, it isn't propositional a priori logic, but empirical evidence that. As for why people take longer, who knows, we simply know from passed experience that it in fact does take longer.

It's extremely frustrating to read Gavin's comments, it's hard to believe he is engaging in earnest discussion.

On Sun, Feb 7, 2016 at 4:01 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Sunday, February 07, 2016 2:16:02 PM Gavin Andresen wrote:
> On Sat, Feb 6, 2016 at 3:46 PM, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Saturday, February 06, 2016 5:25:21 PM Tom Zander via bitcoin-dev
wrote:
> > > If you have a node that is "old" your node will stop getting new
> > > blocks. The node will essentially just say "x-hours behind" with "x"
> > > getting larger every hour. Funds don't get confirmed. etc.
> >
> > Until someone decides to attack you. Then you'll get 6, 10, maybe more
> > blocks confirming a large 10000 BTC payment. If you're just a normal end
> > user (or perhaps an automated system), you'll figure that payment is good
> > and irreversibly hand over the title to the house.
>
> 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%).

I'm assuming there are literally ZERO miners left on the weaker branch.
The attacker in this scenario simply rents hashing for a few days in advance
to build his fake chain, then broadcasts the blocks to the unsuspecting
merchant at ~10 block intervals so it looks like everything is working normal
again. There are lots of mining rental services out there, and miners quite
often do not care to avoid selling hashrate to the highest bidder regardless
of what they're mining. 10 blocks worth costs a little more than 250 BTC -
soon, that will be 125 BTC.

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



--
Steven Pine

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