<p>I think that the problem is not only in program code. There is an ethical problem: How far can the leader of the community go wanting to change something. </p>

<p>Isn't it the same as in "offline" fiat world?</p>

CC BY-SA 3.0
2015-06-05T13:28:30.993Z
`I think that the problem is not only in program code. There is an ethical problem: How far can the leader of the community go wanting to change something?` A leader is meant to lead IMO, but I understand there's community discord. I wanted to clarify it wasn't more a tech issue, as tech issues are easy to solve compared to social ones!
Wizard Of Ozzie
CC BY-SA 3.0
2015-06-05T13:35:19.237Z
What issue? It is not possible to fix perpetuum mobile because it can not exists. It is a fake.
amaclin
CC BY-SA 3.0
2015-06-05T08:07:28.867Z
2015-06-05T08:07:28.867Z
amaclin
<p>There are a number of more complex alternatives under discussion which involve more elastic limits (instead of the hard limit which currently exists), automatically adjusted limits based on some metric in the blockchain, or some combination of both.</p>

<p>More complex alternatives mean more complex code and more potential for bugs. They certainly could and should be tested on testnet.</p>

<p>With the "just raise the hard limit" option (and even with some of the other alternatives), most metrics you could glean from a testnet test aren't very interesting and are already easy to calculate. E.g., it's easy to understand what the worst case bandwidth, CPU, and disk space requirements are, and it's not too difficult to simulate (without testnet) how added block propagation time will (or will not) <a href="http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners" rel="nofollow">affect miner efficiency</a>.</p>

<p>It's the <em>external</em> effects which are causing most of the controversy, e.g.:</p>

<ul>
<li>Will the additional requirements drive more people away from running full nodes, increasing centralization?</li>
<li>Will <a href="http://en.wikipedia.org/wiki/Moore%27s_law" rel="nofollow">Moore's Law</a>, <a href="http://en.wikipedia.org/wiki/Jakob_Nielsen_(usability_consultant)#Contributions" rel="nofollow">Nielsen's Law</a>, and the current <a href="http://en.wikipedia.org/wiki/Mark_Kryder#Kryder_rate" rel="nofollow">Kryder Rate</a> continue into the future, and will they help to improve decentralization despite larger blocks?</li>
<li>Will a "don't do anything until it's an emergency" approach drive people away from Bitcoin when tx confirmation times begin to <a href="http://hashingit.com/analysis/34-bitcoin-traffic-bulletin" rel="nofollow">significantly increase</a> (and Bitcoin Core nodes <a href="https://medium.com/@octskyward/crash-landing-f5cc19908e32" rel="nofollow">begin crashing</a>)? Or will tx space scarcity simply cause tx fees to gradually increase (which will also drive users away if they increase too much, increasing centralization)?</li>
<li>What effect will the blocksize limit have in the future (e.g. on tx fees) as the block subsidy decreases?</li>
</ul>

<p>I'm not trying to list all of the controversial questions/issues (I doubt I even know them), only to demonstrate that there are far more which can't be answered by testnet than can.</p>

CC BY-SA 3.0
2015-06-06T16:20:13.783Z
Fantastic response, mate. I'd be inclined to lean towards a targeted block size, yourself?
Wizard Of Ozzie
CC BY-SA 3.0
2015-06-06T20:23:46.030Z
@WizardOfOzzie Which is the best? I am weary of any solution that tries to set an upper limit based on something stored in the blockchain: the blockchain doesn't know about Moore's Law, etc., and just like PoS systems it might be gameable by participants (miners). I think I like the idea of elastic limits (where miners can pay a "penalty" to increase limits past a soft limit up to a maximum hard limit). Despite the additional code complexity, I think this might be safer from "crashes". Having said all that... I really don't know. It's very complex, and I doubt there's a 100% correct answer.
Christopher Gurnee
CC BY-SA 3.0
2015-06-05T12:36:54.410Z
2015-06-05T12:36:54.410Z
Christopher Gurnee
<p>A stress test was run on mainnet to see the effect of exponential demand in Tx volume.</p>

<p>Why can't a <em>testnet</em> "stress test" be organised to look at the implications of the 20Mb block size (and other variables?) </p>

<p>I can't understand how there's so much speculation when a test environment would solve <em>some</em> of it by delivering actual metrics. </p>

<testnet><testing><blockchain-fork><politics>
Why can't the block size upgrade be trialed on testnet with an organised "stress test"
Wizard Of Ozzie
# Why can't the block size upgrade be trialed on testnet with an organised "stress test"

(Asked by: username_0 on 2015-06-05)

A stress test was run on mainnet to see the effect of exponential demand in Tx volume.

Why can't a *testnet* "stress test" be organised to look at the implications of the 20Mb block size (and other variables?)

I can't understand how there's so much speculation when a test environment would solve *some* of it by delivering actual metrics.

**Tags:** testnet, testing, blockchain-fork, politics


---

## 2 answers

### Answer by username_2 on 2015-06-05. Score: 4 | Accepted answer

There are a number of more complex alternatives under discussion which involve more elastic limits (instead of the hard limit which currently exists), automatically adjusted limits based on some metric in the blockchain, or some combination of both.

More complex alternatives mean more complex code and more potential for bugs. They certainly could and should be tested on testnet.

With the "just raise the hard limit" option (and even with some of the other alternatives), most metrics you could glean from a testnet test aren't very interesting and are already easy to calculate. E.g., it's easy to understand what the worst case bandwidth, CPU, and disk space requirements are, and it's not too difficult to simulate (without testnet) how added block propagation time will (or will not) [affect miner efficiency](http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners).

It's the *external* effects which are causing most of the controversy, e.g.:

* Will the additional requirements drive more people away from running full nodes, increasing centralization?
* Will [Moore's Law](http://en.wikipedia.org/wiki/Moore%27s_law), [Nielsen's Law](http://en.wikipedia.org/wiki/Jakob_Nielsen_(usability_consultant)#Contributions), and the current [Kryder Rate](http://en.wikipedia.org/wiki/Mark_Kryder#Kryder_rate) continue into the future, and will they help to improve decentralization despite larger blocks?
* Will a "don't do anything until it's an emergency" approach drive people away from Bitcoin when tx confirmation times begin to [significantly increase](http://hashingit.com/analysis/34-bitcoin-traffic-bulletin) (and Bitcoin Core nodes [begin crashing](https://medium.com/@octskyward/crash-landing-f5cc19908e32))? Or will tx space scarcity simply cause tx fees to gradually increase (which will also drive users away if they increase too much, increasing centralization)?
* What effect will the blocksize limit have in the future (e.g. on tx fees) as the block subsidy decreases?

I'm not trying to list all of the controversial questions/issues (I doubt I even know them), only to demonstrate that there are far more which can't be answered by testnet than can.

> **Comments:**
> **username_0**: Fantastic response, mate. I'd be inclined to lean towards a targeted block size, yourself?  
> **username_2**: @WizardOfOzzie Which is the best? I am weary of any solution that tries to set an upper limit based on something stored in the blockchain: the blockchain doesn't know about Moore's Law, etc., and just like PoS systems it might be gameable by participants (miners). I think I like the idea of elastic limits (where miners can pay a "penalty" to increase limits past a soft limit up to a maximum hard limit). Despite the additional code complexity, I think this might be safer from "crashes". Having said all that... I really don't know. It's very complex, and I doubt there's a 100% correct answer.  

---

### Answer by username_1 on 2015-06-05. Score: 0

I think that the problem is not only in program code. There is an ethical problem: How far can the leader of the community go wanting to change something.

Isn't it the same as in "offline" fiat world?

> **Comments:**
> **username_0**: `I think that the problem is not only in program code. There is an ethical problem: How far can the leader of the community go wanting to change something?` A leader is meant to lead IMO, but I understand there's community discord. I wanted to clarify it wasn't more a tech issue, as tech issues are easy to solve compared to social ones!  
> **username_1**: What issue? It is not possible to fix perpetuum mobile because it can not exists. It is a fake.  

---

