Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!
Well Well. What do we have here?
This thread has been a lulzy!
In Summary:
Über Evil Blockstream Core have done *something* evil; and Gavin (and his Super-Hero sidekicks) has swept in with is multi-aborted fetus of blocksize increases to save the day!
The problem is that this (dead, rotten, stinking) blocksize increase fetus is starting to get so fowl that even places like Reddit are starting to get a unsavoury taste in their mouths when it is presented as a viable option; yet again.
---
The mailing list on the other hand...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012369.html
Well. Lets just say that if this was a game of football; nobody is watching it for the contest anymore.
This thread has been a lulzy!
In Summary:
Über Evil Blockstream Core have done *something* evil; and Gavin (and his Super-Hero sidekicks) has swept in with is multi-aborted fetus of blocksize increases to save the day!
The problem is that this (dead, rotten, stinking) blocksize increase fetus is starting to get so fowl that even places like Reddit are starting to get a unsavoury taste in their mouths when it is presented as a viable option; yet again.
---
The mailing list on the other hand...
Quote from: Gavin Andresen
[...]
Responding to "28 days is not long enough" :
[...]
Responding to "28 days is not long enough" :
[...]
Quote from: Bryan Bishop
[...]
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.
[...]
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.
[...]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012369.html
Well. Lets just say that if this was a game of football; nobody is watching it for the contest anymore.