Block size increase

[dscotese]

When answering this question, please assume that:

• The software would have a rule built into it to make this happen.
• For option 1, even an orphaned block would trigger.
• "Full Block" means a block in which the amount of room left is less than the average size of transactions in that block.
• "In A Row" excludes orphaned blocks unless they are all orphaned together.
• The results of the poll that you already see are random (this helps eliminate peer pressure - just try it!).
• You'll be able to change your vote later.

As a guard against Bitcoin hurting people who count on it, I chose option 3, but I might change it depending on discussion.  However, I would like to see it become easier for people to change the fee.  It's very easy to forget that a transaction is important enough to have a fee, and broadcast it without one before realizing the risk of delay.  There are two proposals that miners can implement (and some beta code too, I think), called "First-Seen-Safe Replace-By-Fee" FSS-RBF, and "Child Pays For Parent" CPFP that look promising to me.

[1714906182]

1714906182

[1714906182]

1714906182

[1714906182]

1714906182

[jonny1000]

Full blocks, at all times, may be a good thing, regardless of the blocksize limit, for the following reasons:

• Having surplus transactions in the meme pool at all times may be necessary to incentivise miners to move forward when the block reward is low, otherwise miners may not be incentivised to build on the highest block
• Full blocks and surplus transactions in the meme pool means that potential new transactions must outbid these transactions to get in the blockchain, this is healthy for a fee market
• Surplus space in blocks implies a lack of demand, if bitcoin and the network is actually useful, demand should be sufficient to fill all the blocks up

 

[DumbFruit]

This poll is really... Problematic. The problem with the block size is very nuanced. The people, like myself, that are concerned about it don't have some religious conviction about the 1MB block limit specifically. I can't remember reading anyone saying that they dogmatically want to keep the block size at one spot for all eternity. The other problem with the poll is that it's presuming that "full blocks" encapsulates the entire problem; As long as the blocks aren't full there isn't any problem. This ignores the fact that there is a real significant tradeoff in proportion to block size increases.

I could put the problem like this;
What kind of algorithm could be put in place to ensure that the Bitcoin block size limit doesn't need to be hard forked periodically in response to changing technology, market conditions, and node decentralization while simultaneously sustaining funding as inflation diminishes?
Before that question can be answered, one has to come to grips with two other subjective questions; "How decentralized should Bitcoin be?" and "What is a reasonable fee that can allow that to happen?"
These questions all seem to be answered with vague approximations and subjective value judgments which seems preclude any possibility of creating some monolithic algorithm; And hence the protracted and frustrating debate.

Gavin Andresen and Mike Hearn both seem to believe that blocks should never be full. I speculate they don't argue for a simple removal of the block size limit almost entirely for political reasons. I'm sure they would cite "spam" (Whatever that means.) as a mitigating factor.
Regardless, following their solution or some compromise is not simply an argument on technical merits, it's also buying into a particular ideological path for Bitcoin.

Asking, basically, when we should increase the block size after we know they're full is begging the question. Quite a few of them actually.

[Nicolas Dorier]

where is the "I don't care as long as 95% of miners agree" ?

By implementing voting with version number, it is interesting to see that "I don't care as long as 95% of miners agree" can be voted by voting all the BIP at the same time.
First choice to have 95% YES, pass.

On my part, I don't care as long as we find a choice where 95% (miners) are ok for which is not impossible.

An exemple : I am confident that a kick-the-can 2MB can pass the 95% mark, if the miners are confident that the other BIP can be voted later on and are not mutually exclusive.

By the way, I have not read all the mailing list recently but did someone proposed that idea already : https://www.reddit.com/r/Bitcoin/comments/3glp4d/all_block_size_bip_are_not_mutually_exclusives_a/ ?

[amaclin]

where is the "I don't care as long as 95% of miners agree" ?

Why 95?
Why not 51%?

[DumbFruit]

You can, sort of, force the change with 51% of minershashpower, but it would make a big mess. Wladimir J. van der Laan refuses to do any hard forks that don't have broad consensus.

Here's his opinion on that subject;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009137.html

[amaclin]

You can, sort of, force the change with 51% of minershashpower, but it would make a big mess.

Yes. But 51% is a majority. Majority can do whatever it want to do.
51% of minershashpower can vote today and switch to fork tomorrow.

Wladimir J. van der Laan refuses to do any hard forks that don't have broad consensus.
Here's his opinion on that subject;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009137.html

Who is this man?
OK, I know that he is BitcoinCore developer, BitcoinFoundation member, etc, etc, etc...
I mean that he can not speak for majority and I can not rely on his opinion.

[DumbFruit]

You can, sort of, force the change with 51% of minershashpower, but it would make a big mess.

Yes. But 51% is a majority. Majority can do whatever it want to do.
51% of minershashpower can vote today and switch to fork tomorrow.

I wouldn't recommend it.

...a hard fork occurs if a change is made to the protocol such that blocks that are considered valid by one version of the software are not considered valid by another version.  In particular a hard fork occurs when something that is accepted as valid in the new software, wasn't previously accepted as valid in the old software.  This means that blocks from the new software will not be recognized as valid by the old software.  The chain will split if anyone is still running the old software. Depending on how long it takes people to notice that their old software isn't matching the rest of the network, it can create quite a mess for individuals who upgrade and suddenly find that transactions they thought were valid and completed suddenly don't exist.

https://bitcointalk.org/index.php?topic=621996.msg6897607#msg6897607

Wladimir J. van der Laan refuses to do any hard forks that don't have broad consensus.
Here's his opinion on that subject;
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009137.html

Who is this man?
OK, I know that he is BitcoinCore developer, BitcoinFoundation member, etc, etc, etc...
I mean that he can not speak for majority and I can not rely on his opinion.

He's the Bitcoin Core maintainer, he's the one that ultimately decides when to accept pull requests, but you don't have to agree with him. My impression from the mailing list is that all core developers approach hard forks with extreme caution.

[dscotese]

This poll is really... Problematic. ... And hence the protracted and frustrating debate.

Good point.  I added "Let them stay full until we have a better solution than simply doubling it."  Only I suspect you might not want to choose that either because you view the 1MB limit as a problem, and I imagine that you can see the possibility that during the time it takes to find an acceptable solution, the pain of the 1MB limit can get bad enough to justify a change to it.

Would you prefer to suffer the problems of the 1MB limit until a permanent solution is in place?  If not, what would be an acceptable proxy for that pain of those problems that could be used as a trigger for a change, and what would the change be?

Personally, I think a backlog would be mitigated pretty effectively if wallet software made it easier for people to increase the fee on a transaction they already broadcast (like with FSS-RBF or CPFP).  That would buy us a lot of time, and probably (my guess) avoid any trigger implemented according to the results of this poll.  But there may be problems with the 1MB limit other than a growing backlog of transactions.  If so, I'd like to know what they are.

[Nicolas Dorier]

where is the "I don't care as long as 95% of miners agree" ?

Why 95?
Why not 51%?

Because it is how fork worked until now and it worked pretty well without any blood.
But maybe we can propose a BIP that can be voted at 95% to agree with lowering to 51%. 

Now, if 51% fork of the network, I expect we will get two competing currencies on the same blockchain.
What really matter to miner are : can I cash out the coins I am mining on my favorite exchanges ? for how much ?

[amaclin]

Because it is how fork worked until now and it worked pretty well without any blood.
But maybe we can propose a BIP that can be voted at 95% to agree with lowering to 51%. 

The majority of 51% in *any* question means that these votes agree with "blood" today for minority.

[dscotese]

Because it is how fork worked until now and it worked pretty well without any blood.
But maybe we can propose a BIP that can be voted at 95% to agree with lowering to 51%. 

The majority of 51% in *any* question means that these votes agree with "blood" today for minority.

Well, as I understand it, Bitcoin itself declares that 51% means "blood" for the minority.  That is the nature of the beast and there's nothing we can do about it except encourage people to cooperate to avoid giving any psychopath 51% of the mining power.

The big block that caused a fork a long time ago was fixed because a group (of miners) performed what can be described as a "51% attack" against the (minority of) miners (still using the pre-0.8 client) that contained a valid but poison (because of a problem with leveldb, IIRC) block in order to fix Bitcoin.  In that case it was a blessing, and we hope that such a blessing will never be needed again, but if it is, we hope a good person or group controls it, rather than a psychopath.  I think there were times when a mining pool was getting close to holding more than half the hash power, and the operator took some measures to move some of it to other pools... Like what Jeff Berwick would do in Canada if he wins the election ha ha.

[lottery248]

block size increasing would encourage transaction spammers to spread all of the zero value txs into the blockchain.
also, this would not get the bitcoin to be sustainable.
the demand of storage would be skyrocket in order to sustain bitcoin. merchants would get to raise the price of the HDD like what ASIC just did.
not all of the people could afford the HDD and the blockchain size increase.

[amaclin]

Well, as I understand it, Bitcoin itself declares that 51% means "blood" for the minority.

Not only Bitcoin.
This is a common law of nature. Even non-organic nature.
This is centralization.

[DumbFruit]

This poll is really... Problematic. ... And hence the protracted and frustrating debate.

Good point.  I added "Let them stay full until we have a better solution than simply doubling it."  Only I suspect you might not want to choose that either because you view the 1MB limit as a problem, and I imagine that you can see the possibility that during the time it takes to find an acceptable solution, the pain of the 1MB limit can get bad enough to justify a change to it.

This just goes to show how sticky language is. I would like for Bitcoin to handle unlimited transactions, so anything less than that isn't ideal, but at the same time, full blocks don't represent a failure or bug in Bitcoin.

I would be happy to see a change in block sizes, even if it doesn't permanently resolve the issue, when we are seeing an uptick in node count and transaction fees heading in a healthy direction.
Whatever that change is will depend on the data. "Doubling" doesn't seem very well considered to me. Luke-Jr mentioned an increase of 15% to match increasing bandwidth availability. Maybe that's more realistic.

Unfortunately, every indicator I can think of except fee totals has been going in the wrong direction almost monotonically along with the blockchain size increase since 2012 when we started hitting full blocks and responded by increasing the default soft target.  This is frustrating; from a clean slate analysis of network health I think my conclusion would be to _decrease_ the limit below the current 300k/txn/day level.

http://sourceforge.net/p/bitcoin/mailman/message/34090559/
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009466.html

[mmeijeri]

Counting the number of full blocks in a row is a bit restrictive. Why not look at something like what percentage of all blocks in a month was full?

[LiteCoinGuy]

gavins plan is conservativ and a good idea - i follow that plan.

[amaclin]

Counting the number of full blocks in a row is a bit restrictive. Why not look at something like what percentage of all blocks in a month was full?

Because everyone has his own point of view.
The only way to do something - is to do it and wait for others who agree with you in consensus.
All other ways are demagogy and wasting time.

If you want your own rules for BIP-10x - you are welcome to write and publish it.
You are also welcome to make changes in BitcoinCore and publish your client.

[dscotese]

My own thinking on this subject is in constant flux.  Thanks for everyone's input, and I hope more take a look and don't be bashful about changing your mind.

To simplify my position (pretty complicated in my head), I'll say that as soon as FSS-RBF or CPFP is a common solution to having failed to pay a high enough fee, I think I might switch my answer to "Let them stay full until a better solution is found."  I might switch to that answer sooner, but it sucks to be in limbo because you didn't change your (cheapskate) wallet's default fee.