[bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP

Discussion:

Andrew C via bitcoin-dev

2017-02-05 21:50:26 UTC

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

Luke Dashjr via bitcoin-dev

2017-02-05 23:02:28 UTC

Permalink

My BIP draft didn't make progress because the community opposes any block size
increase hardfork ever. Your version doesn't address the current block size
issues (ie, the blocks being too large). 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.

Post by Andrew C via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Andrew C via bitcoin-dev

2017-02-05 23:53:03 UTC

Permalink

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev
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.

Post by Luke Dashjr via bitcoin-dev

Andrew C via bitcoin-dev

2017-02-06 21:00:18 UTC

Permalink

I looked at the discussions about the block size and about Luke-Jr's
proposal on Reddit and Bitcointalk. From what I observed of all of the
discussions is that few users are in favor of the status quo, and even
fewer are in favor of decreasing the block size. The majority of users
favored Segwit because it was a block size increase (that was a commonly
used reason in support of it and in arguments about increasing the block
size).

Discussions about Luke-Jr's proposal indicated that many users disagreed
with the decrease in block size and the time that it took to increase
again to 1 MB. There was not only disagreement but explicit ridicule and
mocking of that aspect of the proposal.

"Many users are of the opposite opinion, that the block size is too
small." - That is newspeak, the users can speak for themselves.
From whom did you gather feedback from before you changed Luke-Jrs BIP?
If people don't agree with the proposal, changing it an infinite
number of times light well lead to the same result.
Have the users spoken, in their response to what Luke-Jr proposed?
On 6 February 2017 00:53:03 CET, Andrew C via bitcoin-dev
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------------------------------------------------
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

t. khan via bitcoin-dev

2017-02-06 18:19:43 UTC

Permalink

Post by Luke Dashjr via bitcoin-dev
My BIP draft didn't make progress because the community opposes any block size
increase hardfork ever.

Luke, how do you know the community opposes that? Specifically, how did you
come to this conclusion?

Post by Luke Dashjr via bitcoin-dev
Your version doesn't address the current block size
issues (ie, the blocks being too large).

Why do you think blocks are "too large"? Please cite some evidence. I've
asked this before and you ignored it, but an answer would be helpful to the
discussion.

- t.k.

On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <

Post by Luke Dashjr via bitcoin-dev
My BIP draft didn't make progress because the community opposes any block size
increase hardfork ever. Your version doesn't address the current block size
issues (ie, the blocks being too large). 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.

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

t. khan via bitcoin-dev

2017-02-06 20:25:13 UTC