<p>The strongest arguments against dynamic blocksizes which can be determined by miner actions, is that they do not necessarily represent the interests of other participants such as users, node operators, or even all miners. </p>

<p>If miners setting the blocksize have good equipment and connections, they may want blocks so large that others are forced off the network. This could include large miners (with the best equipment and network connectivity) forcing smaller miners off the network. Alternately, (some) miners may want a small blocksize while others would prefer a larger one, but be unable to exert any real influence.</p>

<p>Other issues may include concerns that a specific algorithm could grow too fast, too slow, down not allow for downward scaling if usage decreases, or could be attacked.</p>

<p>In summary there is significant:</p>

<ul>
<li>Difficulty in designing an adaptive blocksize formula that cannot be
"gamed" </li>
<li>Difficulty in creating the best model to minimize cost of
node-option (CONOP) </li>
<li>Difficulty in designing a system that can
efficiently scale both up and down </li>
<li>Time and expense to compare
alternative formulas and thoroughly testing them</li>
</ul>

<p>Finding the optimal CONOP model that can satisfy the above concerns will be difficult and time consuming. Until then blocksize limits previously set by humans (and possibly adjusted by humans to allow for more time to study/research codified adaptive blocksize solutions) is the best option available.</p>

<p>CONOP was introduced in this article by Paul Sztorc:</p>

<p><a href="http://www.truthcoin.info/blog/measuring-decentralization/">http://www.truthcoin.info/blog/measuring-decentralization/</a> </p>

<p>The concept in the context of adaptive blocksizes was also recently discussed at the Bitcoin On Chain Scaling conference by Riccardo Spagni:</p>

<p><a href="https://www.youtube.com/watch?v=mM2ra-LzMQk">https://www.youtube.com/watch?v=mM2ra-LzMQk</a></p>

CC BY-SA 3.0
2016-06-29T04:01:36.883Z
Not entirely related, but I feel like the use of the acronym CONOP to mean "cost of node-option" is a poor choice. This acronym is already very widely used to mean "concept of operations". I guess CON for cost-of-node isn't very appealing. Maybe COSUN for cost-of-setting-up-node or something. I realize that this was Mr. Sztorc's choice, not yours, just commenting.
jwinterm
CC BY-SA 3.0
2016-06-29T23:38:40.870Z
I thought it was "Cost of node operation"? You're probably referring to @fluffyponyza's presentation at the On Chain Scaling conference?
Murch
CC BY-SA 3.0
2016-06-28T19:45:48.253Z
2016-06-28T20:00:15.383Z
2016-06-28T20:00:15.383Z
seek adventure
<p>Besides the risk of miners artificially increasing the average block size on purpose, what are some of the potential negatives of adaptive blocksizes?</p>

<p>Are there any advantages of human set hard limits? Are there any advantages of requiring periodic human intervention to evaluate and modify blocksize limits instead of codifying that task?</p>

CC BY-SA 3.0
2016-06-28T12:15:36.167Z
It feels like you're already answering 90% of the question. Perhaps you should split part of your question into an answer on the question instead.
Murch
CC BY-SA 3.0
2016-06-28T19:47:39.863Z
@Murch Based on your comment and the fact that it has been 16 hours since I posted the question, I made the adjustments you suggested.
seek adventure
<scalability><blocksize>
Arguments against Bitcoin using adaptive blocksizes
seek adventure
# Arguments against Bitcoin using adaptive blocksizes

(Asked by: username_0 on 2016-06-28)

Besides the risk of miners artificially increasing the average block size on purpose, what are some of the potential negatives of adaptive blocksizes?

Are there any advantages of human set hard limits? Are there any advantages of requiring periodic human intervention to evaluate and modify blocksize limits instead of codifying that task?

**Tags:** scalability, blocksize

> **Comments:**
> **username_1**: It feels like you're already answering 90% of the question. Perhaps you should split part of your question into an answer on the question instead.  
> **username_0**: @username_1 Based on your comment and the fact that it has been 16 hours since I posted the question, I made the adjustments you suggested.  

---

## 1 answers

### Answer by username_0 on 2016-06-28. Score: 6

The strongest arguments against dynamic blocksizes which can be determined by miner actions, is that they do not necessarily represent the interests of other participants such as users, node operators, or even all miners.

If miners setting the blocksize have good equipment and connections, they may want blocks so large that others are forced off the network. This could include large miners (with the best equipment and network connectivity) forcing smaller miners off the network. Alternately, (some) miners may want a small blocksize while others would prefer a larger one, but be unable to exert any real influence.

Other issues may include concerns that a specific algorithm could grow too fast, too slow, down not allow for downward scaling if usage decreases, or could be attacked.

In summary there is significant:

* Difficulty in designing an adaptive blocksize formula that cannot be
  "gamed"
* Difficulty in creating the best model to minimize cost of
  node-option (CONOP)
* Difficulty in designing a system that can
  efficiently scale both up and down
* Time and expense to compare
  alternative formulas and thoroughly testing them

Finding the optimal CONOP model that can satisfy the above concerns will be difficult and time consuming. Until then blocksize limits previously set by humans (and possibly adjusted by humans to allow for more time to study/research codified adaptive blocksize solutions) is the best option available.

CONOP was introduced in this article by Paul Sztorc:

<http://www.truthcoin.info/blog/measuring-decentralization/>

The concept in the context of adaptive blocksizes was also recently discussed at the Bitcoin On Chain Scaling conference by Riccardo Spagni:

<https://www.youtube.com/watch?v=mM2ra-LzMQk>

> **Comments:**
> **username_2**: Not entirely related, but I feel like the use of the acronym CONOP to mean "cost of node-option" is a poor choice. This acronym is already very widely used to mean "concept of operations". I guess CON for cost-of-node isn't very appealing. Maybe COSUN for cost-of-setting-up-node or something. I realize that this was Mr. Sztorc's choice, not yours, just commenting.  
> **username_1**: I thought it was "Cost of node operation"? You're probably referring to @fluffyponyza's presentation at the On Chain Scaling conference?  

---

