3

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.

Wizard Of Ozzie
  • 5,268
  • 4
  • 30
  • 63

2 Answers2

4

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.

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, Nielsen's Law, and the current 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 (and Bitcoin Core nodes begin crashing)? 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.

Christopher Gurnee
  • 2,493
  • 15
  • 22
  • Fantastic response, mate. I'd be inclined to lean towards a targeted block size, yourself? – Wizard Of Ozzie Jun 06 '15 at 16:20
  • 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. – Christopher Gurnee Jun 06 '15 at 20:23
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?

amaclin
  • 6,718
  • 1
  • 20
  • 32
  • `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 Jun 05 '15 at 13:28
  • 1
    What issue? It is not possible to fix perpetuum mobile because it can not exists. It is a fake. – amaclin Jun 05 '15 at 13:35