Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:On Tue, Aug 18, 2015 at ...
📅 Original date posted:2015-08-19
📝 Original message:On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
<bitcoin-dev at 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).
> 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.
📝 Original message:On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev
<bitcoin-dev at 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).
> 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.