📅 Original date posted:2015-08-19
📝 Original message:Jorge Timón 於 2015-08-19 05:24 寫到:
> 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).
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
jl2012 at xbt.hk [ARCHIVE] /
npub1kc…wjfw4
2023-06-07 15:48:18
in reply to nevent1q…m22g
Author Public Key
npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4Published at
2023-06-07 15:48:18Event JSON
{
"id": "f89a1f7bb93a28f27ab3651f5cf10ae9fb3184a2a997f66486db2ba8b1ff091d",
"pubkey": "b61e2e7ccbf4abd7f49715c62f4ac7a93cbdd5ead0316279c5f5fe9b18dd0aaa",
"created_at": 1686152898,
"kind": 1,
"tags": [
[
"e",
"d1741ba43ee3659ec018c6d08510dcfe36f706cba8efd0c9670cfaa6540ca5b4",
"",
"root"
],
[
"e",
"eb75ffc847f91af8beb3385cfecef9eb33d1649aa20720736c59d76ebfe69558",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-19\n📝 Original message:Jorge Timón 於 2015-08-19 05:24 寫到:\n\u003e On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e As I understand, there is already a consensus among core dev that \n\u003e\u003e block size\n\u003e\u003e should/could be raised. The remaining questions are how, when, how \n\u003e\u003e much, and\n\u003e\u003e how fast. These are the questions for the coming Bitcoin Scalability\n\u003e\u003e Workshops but immediate consensus in these issues are not guaranteed.\n\u003e\u003e \n\u003e\u003e Could we just stop the debate for a moment, and agree to a scheduled\n\u003e\u003e experimental hardfork?\n\u003e\u003e \n\u003e\u003e Objectives (by order of importance):\n\u003e\u003e \n\u003e\u003e 1. The most important objective is to show the world that reaching \n\u003e\u003e consensus\n\u003e\u003e for a Bitcoin hardfork is possible. If we could have a successful one, \n\u003e\u003e we\n\u003e\u003e would have more in the future\n\u003e \n\u003e Apart from classifying all potential consensus rule changes and\n\u003e recommend a deployment path for each case, deploying an\n\u003e uncontroversial hardfork is one of the main goals of bip99:\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html\n\u003e \n\u003e\u003e 2. With a slight increase in block size, to collect data for future\n\u003e\u003e hardforks\n\u003e \n\u003e The uncontroversial hardfork doesn't need to change the maximum block\n\u003e size: there's plenty of hardfork proposals out there, some of them\n\u003e very well tested (like the proposed hardfork in bip99).\n\nYou misunderstand my intention. The experiment is not about a random \nhardfork. It's about a block size increase hardfork. The data will help \nus to design further hardfork on block size.\n\nTo make it less controversial, the size must not be too big.\n\nTo allow a meaningful experiment, the size must not be too small. \nTechnically we could make it 1.01MB but that defeats all objectives I \nlisted and there is no point to do it.\n\nThat's why I suggest 1.5MB.\n\n\u003e\u003e 1. Today, we all agree that some kind of block size hardfork will \n\u003e\u003e happen on\n\u003e\u003e t1=*1 June 2016*\n\u003e \n\u003e I disagree with this. I think it should be schedule at least a year\n\u003e after it is deployed in the newest versions.\n\u003e Maybe there's something special about June 2016 that I'm missing.\n\nI hope the fork could be done before the halving, which (hopefully) we \nmay have a new bitcoin rush\n\nThere was only 2 months for the BIP50 hardfork. You may argue that's a \n\"bug fix\" but practically there is no difference: people not fixing the \nbug in 2 months was forked off. Four months of grace period (Feb to June \n2016) is already a double of that.\n\nAlso, if we could have zero grace period for softfork, why must we have \na ultra-long period for hardfork? (Unless you also agree to have an \n1-year grace period for softfork. I don't buy the \"softfork is safer \nthan hardfork\" theory. The recent BIP66 fork has clearly shown why it is \nwrong: non-upgrading full nodes are not full nodes)\n\nThe problem is many people won't update until they must do so. So 4 \nmonths or 1 year make little difference",
"sig": "851a01e848da50151a39884d158e99b0160488be3406e1af36655f0436db1602c1c576c0a7051c5ea4eb734140131652753da26532f2a4d2c2e94e6e86ba1b06"
}