📅 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.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:36:45
in reply to nevent1q…mjge
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:36:45Event JSON
{
"id": "090459b8b70cced682b660985fef31fa52d99ef847f59b2bcc09e66e46d7d884",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686159405,
"kind": 1,
"tags": [
[
"e",
"015c5ac0a5b1780b314fc0de46b00e614fb9247d46dfb61637d3d94fa76f544c",
"",
"root"
],
[
"e",
"82cd1c5191cee7185db1044bfdfb846554ced53d72a1e21950a59c236682b19f",
"",
"reply"
],
[
"p",
"e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e As I understand, there is already a consensus among core dev that block size\n\u003e should/could be raised. The remaining questions are how, when, how much, and\n\u003e how fast. These are the questions for the coming Bitcoin Scalability\n\u003e Workshops but immediate consensus in these issues are not guaranteed.\n\u003e\n\u003e Could we just stop the debate for a moment, and agree to a scheduled\n\u003e experimental hardfork?\n\u003e\n\u003e Objectives (by order of importance):\n\u003e\n\u003e 1. The most important objective is to show the world that reaching consensus\n\u003e for a Bitcoin hardfork is possible. If we could have a successful one, we\n\u003e would have more in the future\n\nApart from classifying all potential consensus rule changes and\nrecommend a deployment path for each case, deploying an\nuncontroversial hardfork is one of the main goals of bip99:\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html\n\n\u003e 2. With a slight increase in block size, to collect data for future\n\u003e hardforks\n\nThe uncontroversial hardfork doesn't need to change the maximum block\nsize: there's plenty of hardfork proposals out there, some of them\nvery well tested (like the proposed hardfork in bip99).\n\n\u003e 1. Today, we all agree that some kind of block size hardfork will happen on\n\u003e t1=*1 June 2016*\n\nI disagree with this. I think it should be schedule at least a year\nafter it is deployed in the newest versions.\nMaybe there's something special about June 2016 that I'm missing.",
"sig": "2ad0947efbef86fd43de527785fadba0420e8792de7e51f0cd95457a6280c0135ca8bac3f8420faaa1763e63b1294d949972c817918174af29d00a00041fc858"
}