Many people have expressed discontent with Luke-jr's proposed block sizeBIP, in particular with the decrease in size that would occur if it wereto be activated prior to 2024.

I have decided to modify the proposal to instead begin the increasesteps at the current 1000000 byte limit. The increases and the time spamof each increase will remain the same, just that the increase beginsfrom 1000000 bytes instead of 300000 bytes.

Furthermore, instead of a fixed schedule from a fixed point in time, theincreases will instead be calculated off of the MTP of the activationblock (the first block to be in the active state for this fork).

While this proposal shares many of the same issues with the one itmodifies, I hope that it will be slightly less controversial and canallow us to move forward with scaling Bitcoin.

The full text of the proposal can be found athttps://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.My implementation of it is available athttps://github.com/achow101/bitcoin/tree/bip-blksize

My BIP draft didn't make progress because the community opposes any block sizeincrease hardfork ever. Your version doesn't address the current block sizeissues (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 thepoint. Also, your version is now EXCLUSIVELY a hardfork, so it makes no senseto 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-devHello all,Many people have expressed discontent with Luke-jr's proposed block sizeBIP, in particular with the decrease in size that would occur if it wereto be activated prior to 2024.I have decided to modify the proposal to instead begin the increasesteps at the current 1000000 byte limit. The increases and the time spamof each increase will remain the same, just that the increase beginsfrom 1000000 bytes instead of 300000 bytes.Furthermore, instead of a fixed schedule from a fixed point in time, theincreases will instead be calculated off of the MTP of the activationblock (the first block to be in the active state for this fork).While this proposal shares many of the same issues with the one itmodifies, I hope that it will be slightly less controversial and canallow us to move forward with scaling Bitcoin.The full text of the proposal can be found athttps://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.My implementation of it is available athttps://github.com/achow101/bitcoin/tree/bip-blksizeAndrew_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

From what I have observed, it seems to be that people are more soopposed to a hard fork when there is a comparable soft fork availablethan simply opposed to any block size increase hard fork ever. From thevarious threads discussing your proposal, it seemed that many wouldfavor it if it increased over 1 MB sooner or if it never even decreasedin the first place.

Many users are of the opposite opinion, that the block size is toosmall. I understand that the decrease is to allow the blockchain size togrow more slowly thereby allowing users to be more likely to run fullnodes. Unfortunately, I think that we are way past the point of noreturn on that. The blockchain is already 100+ GB. Decreasing the blocksize is not going to make that any smaller and is not going to make itany less painful to run a full node. Given that in order to start up anew full node will still require downloading at least 100 GB of data, Idon't think that decreasing the block size will better facilitate fullnode creation. Furthermore, the current trend with ISPs (at least in theUS) is implementing data and bandwidth caps so users are still unlikelyto start up new full nodes regardless of any changes that we cancurrently do.

Post by Luke Dashjr via bitcoin-devSo you've retained the only certain-DOA parts of my proposal, and removed the most useful part... I'm not sure thepoint. Also, your version is now EXCLUSIVELY a hardfork, so it makes no senseto 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 forcomment on the modified block size schedule. I just kept the deploymentas it was originally. However, we could use a modified version of BIP 9by using one of the top three bits and a longer locked-in period as agrace period for all users to upgrade.

Post by Andrew C via bitcoin-devHello all,Many people have expressed discontent with Luke-jr's proposed block sizeBIP, in particular with the decrease in size that would occur if it wereto be activated prior to 2024.I have decided to modify the proposal to instead begin the increasesteps at the current 1000000 byte limit. The increases and the time spamof each increase will remain the same, just that the increase beginsfrom 1000000 bytes instead of 300000 bytes.Furthermore, instead of a fixed schedule from a fixed point in time, theincreases will instead be calculated off of the MTP of the activationblock (the first block to be in the active state for this fork).While this proposal shares many of the same issues with the one itmodifies, I hope that it will be slightly less controversial and canallow us to move forward with scaling Bitcoin.The full text of the proposal can be found athttps://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.My implementation of it is available athttps://github.com/achow101/bitcoin/tree/bip-blksizeAndrew_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I looked at the discussions about the block size and about Luke-Jr'sproposal on Reddit and Bitcointalk. From what I observed of all of thediscussions is that few users are in favor of the status quo, and evenfewer are in favor of decreasing the block size. The majority of usersfavored Segwit because it was a block size increase (that was a commonlyused reason in support of it and in arguments about increasing the blocksize).

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

"Many users are of the opposite opinion, that the block size is toosmall." - 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 infinitenumber 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-devMy BIP draft didn't make progress because the communityopposes any block size increase hardfork ever.From what I have observed, it seems to be that people are more soopposed to a hard fork when there is a comparable soft fork availablethan simply opposed to any block size increase hard fork ever. From thevarious threads discussing your proposal, it seemed that many wouldfavor it if it increased over 1 MB sooner or if it never even decreasedin 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 toosmall. I understand that the decrease is to allow the blockchain size togrow more slowly thereby allowing users to be more likely to run fullnodes. Unfortunately, I think that we are way past the point of noreturn on that. The blockchain is already 100+ GB. Decreasing the blocksize is not going to make that any smaller and is not going to make itany less painful to run a full node. Given that in order to start up anew full node will still require downloading at least 100 GB of data, Idon't think that decreasing the block size will better facilitate fullnode creation. Furthermore, the current trend with ISPs (at least in theUS) is implementing data and bandwidth caps so users are still unlikelyto start up new full nodes regardless of any changes that we cancurrently 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 makesno sense to keep the BIP 9 deployment at all - either it getsconsensus or it doesn't, but miners have no part in deploymentof it.Yes, I know deployment needs to be fixed. I was more proposing this forcomment on the modified block size schedule. I just kept the deploymentas it was originally. However, we could use a modified version of BIP 9by using one of the top three bits and a longer locked-in period as agrace period for all users to upgrade.On Sunday, February 05, 2017 9:50:26 PM Andrew C viaHello all, Many people have expressed discontent withLuke-jr's proposed block size BIP, in particular with thedecrease in size that would occur if it were to beactivated prior to 2024. I have decided to modify theproposal to instead begin the increase steps at thecurrent 1000000 byte limit. The increases and the timespam of each increase will remain the same, just that theincrease begins from 1000000 bytes instead of 300000bytes. Furthermore, instead of a fixed schedule from afixed point in time, the increases will instead becalculated off of the MTP of the activation block (thefirst block to be in the active state for this fork).While this proposal shares many of the same issues withthe one it modifies, I hope that it will be slightly lesscontroversial and can allow us to move forward withscaling Bitcoin. The full text of the proposal can befound athttps://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.My implementation of it is available athttps://github.com/achow101/bitcoin/tree/bip-blksize Andrew------------------------------------------------------------------------bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev------------------------------------------------------------------------bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

- t.k.

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

Post by Luke Dashjr via bitcoin-devMy BIP draft didn't make progress because the community opposes any block sizeincrease hardfork ever. Your version doesn't address the current block sizeissues (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 thepoint. Also, your version is now EXCLUSIVELY a hardfork, so it makes no senseto 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-devHello all,Many people have expressed discontent with Luke-jr's proposed block sizeBIP, in particular with the decrease in size that would occur if it wereto be activated prior to 2024.I have decided to modify the proposal to instead begin the increasesteps at the current 1000000 byte limit. The increases and the time spamof each increase will remain the same, just that the increase beginsfrom 1000000 bytes instead of 300000 bytes.Furthermore, instead of a fixed schedule from a fixed point in time, theincreases will instead be calculated off of the MTP of the activationblock (the first block to be in the active state for this fork).While this proposal shares many of the same issues with the one itmodifies, I hope that it will be slightly less controversial and canallow us to move forward with scaling Bitcoin.The full text of the proposal can be found athttps://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.My implementation of it is available athttps://github.com/achow101/bitcoin/tree/bip-blksizeAndrew_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Doing nothing is the rules we all agreed to. If those rules are to bechanged,nearly everyone will need to consent. The same rule applies to thecap, we all agreed to 21m, and if someone wants to change that, nearlyeveryone would need to agree.

On Feb 8, 2017 10:28 AM, "Andrew Johnson" <***@gmail.com>wrote:

It is when you're talking about making a choice and 6.3x more people prefersomething else. Doing nothing is a choice as well.

Put another way, if 10% supported increasing the 21M coin cap and 63% wereagainst, would you seriously consider doing it?

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Even ignoring the obvious flaws of that poll, Andrew is still correct: youcannot reach 100% consensus. It's statistically impossible in any largegroup.

Only the majority needs to consent, though what is considered a majorityvaries depending on the context (95%, 75%, 51%). Nowhere does it say"everyone needs to agree".

Post by alp alp via bitcoin-devDoing nothing is the rules we all agreed to. If those rules are to bechanged,nearly everyone will need to consent. The same rule applies to thecap, we all agreed to 21m, and if someone wants to change that, nearlyeveryone would need to agree.It is when you're talking about making a choice and 6.3x more peopleprefer something else. Doing nothing is a choice as well.Put another way, if 10% supported increasing the 21M coin cap and 63% wereagainst, would you seriously consider doing it?

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselvescome downto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

If a small dissenting minority can block all forward progress then bitcoinis no longer interesting. What an incredibly simple attack vector...

No need to break any cryptography, find a bug to exploit, build tens ofmillions of dollars in mining hardware, spend lots of bitcoin on fees toflood the network, or be clever or expend any valuable resources in anyway, shape, or form.

Just convince(or pay, if you do want to expend some resources) a fewpeople(or make up a few online personas) to staunchly refuse to acceptanything at all and the entire system is stuck in 2013(when we firststarted widely discussing a blocksize increase seriously).

Is that really the bitcoin that you want to be a part of?

When the 1MB cap was implemented it was stated specifically that we couldincrease it when we needed it. The white paper even talks about scaling tohuge capacity. Not sure where you got the idea that we all agreed to stayat 1MB forever, I certainly didn't. It was never stated or implied that wecould change the coin cap later(please cite if I'm mistaken).

On Feb 8, 2017 12:16 PM, "alp alp" <***@gmail.com> wrote:

Doing nothing is the rules we all agreed to. If those rules are to bechanged,nearly everyone will need to consent. The same rule applies to thecap, we all agreed to 21m, and if someone wants to change that, nearlyeveryone would need to agree.

On Feb 8, 2017 10:28 AM, "Andrew Johnson" <***@gmail.com>wrote:

It is when you're talking about making a choice and 6.3x more people prefersomething else. Doing nothing is a choice as well.

Put another way, if 10% supported increasing the 21M coin cap and 63% wereagainst, would you seriously consider doing it?

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

increase it when we needed it. The white paper even talks about scaling tohuge capacity. Not sure where you got the idea that we all agreed to stayat 1MB forever, I certainly didn't. It was never stated or implied that wecould change the coin cap later(please cite if I'm mistaken).

The community has not agreed that it is needed at this time. Perhaps theywill change their mind at some point in the future. We have also learned agreat deal since the publication of the initial whitepaper, such as theunstable state without a backlog or subsidy. Fortunately, participation inthis system is voluntary, and you are free to leave at any time.

This seems to be venturing quite off topic, and perhaps would be bettersuited for the bitcoin-discuss list.

Post by t. khan via bitcoin-devIf a small dissenting minority can block all forward progress then bitcoinis no longer interesting. What an incredibly simple attack vector...No need to break any cryptography, find a bug to exploit, build tens ofmillions of dollars in mining hardware, spend lots of bitcoin on fees toflood the network, or be clever or expend any valuable resources in anyway, shape, or form.Just convince(or pay, if you do want to expend some resources) a fewpeople(or make up a few online personas) to staunchly refuse to acceptanything at all and the entire system is stuck in 2013(when we firststarted widely discussing a blocksize increase seriously).Is that really the bitcoin that you want to be a part of?When the 1MB cap was implemented it was stated specifically that we couldincrease it when we needed it. The white paper even talks about scaling tohuge capacity. Not sure where you got the idea that we all agreed to stayat 1MB forever, I certainly didn't. It was never stated or implied that wecould change the coin cap later(please cite if I'm mistaken).Doing nothing is the rules we all agreed to. If those rules are to bechanged,nearly everyone will need to consent. The same rule applies to thecap, we all agreed to 21m, and if someone wants to change that, nearlyeveryone would need to agree.It is when you're talking about making a choice and 6.3x more peopleprefer something else. Doing nothing is a choice as well.Put another way, if 10% supported increasing the 21M coin cap and 63% wereagainst, would you seriously consider doing it?

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselvescome downto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Agreed, this thread is venturing somewhat out of scope for the list. Pleasecan we redirect philosophical discussion to another forum/list such asbitcoin-discuss, which can be found athttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss

varies depending on the context (95%, 75%, 51%). Nowhere does it say"everyone needs to agree".There's a pretty huge gap between 90% and nearly 100%. 90% excluding 10%only 7 times results in only 48% of the original base.

could increase it when we needed it. The white paper even talks aboutscaling to huge capacity. Not sure where you got the idea that we allagreed to stay at 1MB forever, I certainly didn't. It was never stated orimplied that we could change the coin cap later(please cite if I'mmistaken).The community has not agreed that it is needed at this time. Perhaps theywill change their mind at some point in the future. We have also learned agreat deal since the publication of the initial whitepaper, such as theunstable state without a backlog or subsidy. Fortunately, participation inthis system is voluntary, and you are free to leave at any time.This seems to be venturing quite off topic, and perhaps would be bettersuited for the bitcoin-discuss list.

Post by t. khan via bitcoin-devIf a small dissenting minority can block all forward progress thenbitcoin is no longer interesting. What an incredibly simple attackvector...No need to break any cryptography, find a bug to exploit, build tens ofmillions of dollars in mining hardware, spend lots of bitcoin on fees toflood the network, or be clever or expend any valuable resources in anyway, shape, or form.Just convince(or pay, if you do want to expend some resources) a fewpeople(or make up a few online personas) to staunchly refuse to acceptanything at all and the entire system is stuck in 2013(when we firststarted widely discussing a blocksize increase seriously).Is that really the bitcoin that you want to be a part of?When the 1MB cap was implemented it was stated specifically that we couldincrease it when we needed it. The white paper even talks about scaling tohuge capacity. Not sure where you got the idea that we all agreed to stayat 1MB forever, I certainly didn't. It was never stated or implied that wecould change the coin cap later(please cite if I'm mistaken).Doing nothing is the rules we all agreed to. If those rules are to bechanged,nearly everyone will need to consent. The same rule applies to thecap, we all agreed to 21m, and if someone wants to change that, nearlyeveryone would need to agree.It is when you're talking about making a choice and 6.3x more peopleprefer something else. Doing nothing is a choice as well.Put another way, if 10% supported increasing the 21M coin cap and 63%were against, would you seriously consider doing it?

The reason people stop running nodes is because there's no incentiveto counteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

"10% say literally never. That seems like a significant disenfranchisementand lack of consensus."

Certainly the poll results should be taken with a grain of salt and not a definitive answer or measure .However if we agree the poll has some worth (or even if not, then lets use it as hyptothetical): If we split it into two groups: those okay with a hardfork at some point > now, and those never okay with hardfork, that means there is 90% that agree a hardfork is acceptable in the future. That said, what threshold defines consensus then? 98%? 100%?

Personally I think pursuing paths that maximize net social benefit in terms of cost surplus/burden is the best way to go since consensus is such an impossible to define, variable, case-by-case thing that doesn't always lead to the best choice.

To subscribe or unsubscribe via the World Wide Web, visithttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-devor, via email, send a message with subject or body 'help' tobitcoin-dev-***@lists.linuxfoundation.org

You can reach the person managing the list atbitcoin-dev-***@lists.linuxfoundation.org

When replying, please edit your Subject line so it is more specificthan "Re: Contents of bitcoin-dev digest..."

Full node count is far below the safe minimum of 85% of economic activity.

Is this causing a problem now? If so, what?

Typically reasons given for people not using full nodes themselves comedownto the high resource requirements caused by the block size.

The reason people stop running nodes is because there's no incentive tocounteract the resource costs. Attempting to solve this by making blocks*smaller* is like curing a disease by killing the patient. (Incentivizingfull node operation would fix that problem.)- t.k._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------An HTML attachment was scrubbed...URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170208/18d9cda5/attachment-0001.html>