On Sat, Feb 6, 2016 at 9:37 AM, Gavin Andresen wrote:
Responding to "28 days is not long enough" :
Gavin,
Thank you for the emails. Bitcoin Core has been working with the Bitcoin ecosystem on developing and now testing a new capacity increasing feature called segregated witness (segwit). Segregated witness is a voluntary, mutually backwards-compatible capacity upgrade for the Bitcoin system. Many, many hundreds of millions of dollars of Bitcoin value have flowed through soft-forked upgrades to the Bitcoin system, representing upgrades from across the entire ecosystem and the entire Bitcoin network, over multiple years including BIP 12, BIP 16, BIP 17, BIP 30, BIP 34, BIP 42, BIP 62, BIP 65, BIP 66, etc. So that’s the context from which I have been approaching your hard-fork ideas for the past year.
Benefits of segregated witness
Ecosystem buy-in and support for segregated witness continues to grow:
There is also a segwit testnet which everyone is encouraged to investigate and develop against-- companies love them some testing, after all:
A plan for Bitcoin Core capacity increases was put forward and can be found here:
With respect, the question should not be "is 28 days enough time for anyone to roll out new binaries", it's instead a question of "how long does it take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why would they agree when 10% of the hashpower is setting some flag in a block? Why would they change their minds at 20%? 90%? I am not saying here that hard-forks should never be attempted, although we need as an ecosystem to develop much more rigor and a more data-driven approach, and while that might be hard to define exactly, as was once said by regulators, “I know it when I see it”. Companies in the financial sector give a year or more before deprecating old APIs even after the new one has been up and running concurrently and well proven, and would not shut off their old one in order to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the existing rules? What would that mean? Are you willing to maintain two separate networks, and if not, would you please document this in your BIP? Deprecation timeline and emergency procedures?? Should we include rationalizations for not using a new address prefix? In the event of a partial hard-fork where two chains exist, wouldn't it make more sense to have the new chain use a new address prefix? Using a new address prefix could conceivably serve to minimize the impact of what almost looks like an intentionally constructed y2k-bug type of event for the ecosystem.
I suspect that soft-fork upgrades have in the past tolerated _less_ rigor around planning because voluntary soft-fork upgrading does not intentionally break backwards-compatibility. Over time I expect that even soft-fork upgrades will have much more planning, but again, it seems that incompatible changes require much more rigor. If the sky is truly falling according to your pronouncements, then there are millions if not billions of dollars of value on the line which are being risked from lack of engineering rigor without a well documented procedure, and suggesting that we agree on that "next time" is not going to create the results that meet your or anyone else’s desire. Much more, we need to signal to the broader ecosystem and world that we are serious, mature and ready for business.
Regarding your request for definitions about soft-hard forks and generalized soft-forks, you can find some definitions over here:
About hard-forks you may be interested in reading and internalizing,
This was an interesting exploration of soft-forks and hard-forks:
On the security of soft-forks
Are soft-forks misnamed?
- Bryan