📅 Original date posted:2017-02-05
📝 Original message:On 2/5/2017 6:02 PM, Luke Dashjr wrote:
> My BIP draft didn't make progress because the community opposes any block size
> increase hardfork ever.
From what I have observed, it seems to be that people are more so
opposed to a hard fork when there is a comparable soft fork available
than simply opposed to any block size increase hard fork ever. From the
various threads discussing your proposal, it seemed that many would
favor it if it increased over 1 MB sooner or if it never even decreased
in the first place.
> Your version doesn't address the current block size
> issues (ie, the blocks being too large).
Many users are of the opposite opinion, that the block size is too
small. I understand that the decrease is to allow the blockchain size to
grow more slowly thereby allowing users to be more likely to run full
nodes. Unfortunately, I think that we are way past the point of no
return on that. The blockchain is already 100+ GB. Decreasing the block
size is not going to make that any smaller and is not going to make it
any less painful to run a full node. Given that in order to start up a
new full node will still require downloading at least 100 GB of data, I
don't think that decreasing the block size will better facilitate full
node creation. Furthermore, the current trend with ISPs (at least in the
US) is implementing data and bandwidth caps so users are still unlikely
to start up new full nodes regardless of any changes that we can
currently do.
> So you've retained the only certain-
> DOA parts of my proposal, and removed the most useful part... I'm not sure the
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense
> to keep the BIP 9 deployment at all - either it gets consensus or it doesn't,
> but miners have no part in deployment of it.
Yes, I know deployment needs to be fixed. I was more proposing this for
comment on the modified block size schedule. I just kept the deployment
as it was originally. However, we could use a modified version of BIP 9
by using one of the top three bits and a longer locked-in period as a
grace period for all users to upgrade.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
>> Hello all,
>>
>> Many people have expressed discontent with Luke-jr's proposed block size
>> BIP, in particular with the decrease in size that would occur if it were
>> to be activated prior to 2024.
>>
>> I have decided to modify the proposal to instead begin the increase
>> steps at the current 1000000 byte limit. The increases and the time spam
>> of each increase will remain the same, just that the increase begins
>> from 1000000 bytes instead of 300000 bytes.
>>
>> Furthermore, instead of a fixed schedule from a fixed point in time, the
>> increases will instead be calculated off of the MTP of the activation
>> block (the first block to be in the active state for this fork).
>>
>> While this proposal shares many of the same issues with the one it
>> modifies, I hope that it will be slightly less controversial and can
>> allow us to move forward with scaling Bitcoin.
>>
>> The full text of the proposal can be found at
>> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
>> My implementation of it is available at
>> https://github.com/achow101/bitcoin/tree/bip-blksize
>>
>>
>> Andrew
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Andrew C [ARCHIVE] /
npub1vc…xz0wk
2023-06-07 17:56:02
in reply to nevent1q…cptn
Author Public Key
npub1vceyhqxfhemlfq82ztdv9gqgc08zq2680yzy4dfuly7h8pqrkwps0xz0wkPublished at
2023-06-07 17:56:02Event JSON
{
"id": "345b465189d837aaa5ba4139ae1c90a10318166cfd975ca89dc8b601f50d6c7a",
"pubkey": "66324b80c9be77f480ea12dac2a008c3ce202b4779044ab53cf93d738403b383",
"created_at": 1686160562,
"kind": 1,
"tags": [
[
"e",
"6eddf1a13d41cd54af30531855ceb7d14eb31ca00a80520a5a643c560fb7dfbd",
"",
"root"
],
[
"e",
"b667745a5fbb2bb146fd883ecea822817ec7879b98e2e35342c67e0ac96ba132",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-02-05\n📝 Original message:On 2/5/2017 6:02 PM, Luke Dashjr wrote:\n\u003e My BIP draft didn't make progress because the community opposes any block size \n\u003e increase hardfork ever.\nFrom what I have observed, it seems to be that people are more so\nopposed to a hard fork when there is a comparable soft fork available\nthan simply opposed to any block size increase hard fork ever. From the\nvarious threads discussing your proposal, it seemed that many would\nfavor it if it increased over 1 MB sooner or if it never even decreased\nin the first place.\n\n\u003e Your version doesn't address the current block size \n\u003e issues (ie, the blocks being too large). \nMany users are of the opposite opinion, that the block size is too\nsmall. I understand that the decrease is to allow the blockchain size to\ngrow more slowly thereby allowing users to be more likely to run full\nnodes. Unfortunately, I think that we are way past the point of no\nreturn on that. The blockchain is already 100+ GB. Decreasing the block\nsize is not going to make that any smaller and is not going to make it\nany less painful to run a full node. Given that in order to start up a\nnew full node will still require downloading at least 100 GB of data, I\ndon't think that decreasing the block size will better facilitate full\nnode creation. Furthermore, the current trend with ISPs (at least in the\nUS) is implementing data and bandwidth caps so users are still unlikely\nto start up new full nodes regardless of any changes that we can\ncurrently do.\n\n\u003e So you've retained the only certain-\n\u003e DOA parts of my proposal, and removed the most useful part... I'm not sure the \n\u003e point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense \n\u003e to keep the BIP 9 deployment at all - either it gets consensus or it doesn't, \n\u003e but miners have no part in deployment of it.\nYes, I know deployment needs to be fixed. I was more proposing this for\ncomment on the modified block size schedule. I just kept the deployment\nas it was originally. However, we could use a modified version of BIP 9\nby using one of the top three bits and a longer locked-in period as a\ngrace period for all users to upgrade.\n\u003e\n\u003e On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:\n\u003e\u003e Hello all,\n\u003e\u003e\n\u003e\u003e Many people have expressed discontent with Luke-jr's proposed block size\n\u003e\u003e BIP, in particular with the decrease in size that would occur if it were\n\u003e\u003e to be activated prior to 2024.\n\u003e\u003e\n\u003e\u003e I have decided to modify the proposal to instead begin the increase\n\u003e\u003e steps at the current 1000000 byte limit. The increases and the time spam\n\u003e\u003e of each increase will remain the same, just that the increase begins\n\u003e\u003e from 1000000 bytes instead of 300000 bytes.\n\u003e\u003e\n\u003e\u003e Furthermore, instead of a fixed schedule from a fixed point in time, the\n\u003e\u003e increases will instead be calculated off of the MTP of the activation\n\u003e\u003e block (the first block to be in the active state for this fork).\n\u003e\u003e\n\u003e\u003e While this proposal shares many of the same issues with the one it\n\u003e\u003e modifies, I hope that it will be slightly less controversial and can\n\u003e\u003e allow us to move forward with scaling Bitcoin.\n\u003e\u003e\n\u003e\u003e The full text of the proposal can be found at\n\u003e\u003e https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.\n\u003e\u003e My implementation of it is available at\n\u003e\u003e https://github.com/achow101/bitcoin/tree/bip-blksize\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Andrew\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "f83007bea96f8dd16d6d19b76f335e88aead0f6bbc91fad10d3de4866c1d1bafb88d9f1b658d37ed6dde3d6ebe52ce447cea00f903454f34a1698974d2406186"
}