Jorge Timón 於 2015-08-19 05:24 寫到:
On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
As I understand, there is already a consensus among core dev that
block size
should/could be raised. The remaining questions are how, when, how
much, and
how fast. These are the questions for the coming Bitcoin Scalability
Workshops but immediate consensus in these issues are not guaranteed.
Could we just stop the debate for a moment, and agree to a scheduled
experimental hardfork?
Objectives (by order of importance):
1. The most important objective is to show the world that reaching
consensus
for a Bitcoin hardfork is possible. If we could have a successful one,
we
would have more in the future
Apart from classifying all potential consensus rule changes and
recommend a deployment path for each case, deploying an
uncontroversial hardfork is one of the main goals of bip99:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html
2. With a slight increase in block size, to collect data for future
hardforks
The uncontroversial hardfork doesn't need to change the maximum block
size: there's plenty of hardfork proposals out there, some of them
very well tested (like the proposed hardfork in bip99).
You misunderstand my intention. The experiment is not about a random
hardfork. It's about a block size increase hardfork. The data will help
us to design further hardfork on block size.
To make it less controversial, the size must not be too big.
To allow a meaningful experiment, the size must not be too small.
Technically we could make it 1.01MB but that defeats all objectives I
listed and there is no point to do it.
That's why I suggest 1.5MB.
1. Today, we all agree that some kind of block size hardfork will
happen on
t1=*1 June 2016*
I disagree with this. I think it should be schedule at least a year
after it is deployed in the newest versions.
Maybe there's something special about June 2016 that I'm missing.
I hope the fork could be done before the halving, which (hopefully) we
may have a new bitcoin rush
There was only 2 months for the BIP50 hardfork. You may argue that's a
"bug fix" but practically there is no difference: people not fixing the
bug in 2 months was forked off. Four months of grace period (Feb to June
2016) is already a double of that.
Also, if we could have zero grace period for softfork, why must we have
a ultra-long period for hardfork? (Unless you also agree to have an
1-year grace period for softfork. I don't buy the "softfork is safer
than hardfork" theory. The recent BIP66 fork has clearly shown why it is
wrong: non-upgrading full nodes are not full nodes)
The problem is many people won't update until they must do so. So 4
months or 1 year make little difference
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
