Author

Topic: BIP Proposal: Node’s driven adjustment of block size (Read 564 times)

hero member
Activity: 1302
Merit: 540
If somebody is very rich and he can install many nodes, but he cannot afford many miners, can he control the network by controlling the nodes?
staff
Activity: 3458
Merit: 6793
Just writing some code
This proposal is similar to Bitcoin Unlimited, but slightly better IMO because the block sizes are announced by the node. However, I don't think that having the block size limit being controlled and determined by the node operator is a good idea. It is consensus critical and could result in nodes being left behind and lots of potential forks. It is bad for miners as it could increase their orphan rate much more than previously.

Another question is the default value. Most node operators are going to be lazy and not change the default value.

Can you provide more specific technical details on how the block size limit of a node is announced and how that announcement will be able to reach miners so that they know what block size they should be producing?

Also, please post this to the mailing list and open a PR to the BIPs repository if you want it to be seriously considered by anyone.
full member
Activity: 133
Merit: 100
I've been working on the following BIP and I'm looking for your suggestions and remarks.

Abstract:

- The maximum block size (miners can create) is raised to 32MB.

- Nodes can specify the maximum block size they’ll relay. It can’t be lower than 1MB and the value is publicly announced.

- Miners navigate between the risk of being orphaned and losing on transaction fees.

- 95% Activation threshold.

Motivation:

Miners are motivated by the bitcoin they mine on each block. The revenue is split between block coinbase reward and transaction fees. Greed will push miners to increase the size of the blocks to make more on transaction fees. Fear of the blocks not propagating fast enough will prevent miners from creating blocks that are too big.

The maximum relay value of each node is public. Miners have the duty of researching and analysing the network of bitcoin nodes. They have to determine the right block size to minimise orphan risk and increase profitability.

Specification:

- The maximum block size is set to 32MB.

- The minimum relay value is 1MB. The maximum is 32MB.

- The bitcoin client can automatically determine and adjust the relay value based on the host bandwidth capacity.

- The operator can set the relay value to a fixed amount, but not lower than 1MB.

- The relay value is publicly advertised to other nodes.

Rationale:

= Chinese miners

Most nodes are located in the western world. Most of the hashing power is located in China. It’s possible that a 32MB block that is generated in France, for example, gets propagated quickly through the western world (most of the nodes).

However, Chinese miners won’t be able to download and relay this block. So they’ll mine on another chain with smaller blocks. The network will eventually fork. But the western nodes will adjust again to the chain which has the most proof of work.

This can be a possible attack surface on the network. Nodes can mitigate against this attack by lowering their relay value below their hardware capacity to adjust for the Chinese miners.

= Insights into the network capacity

By making the relay value public, economic operators and miners have a valuable insight into the network capacity.

Miners will decide the size of blocks they create based on this data. There will be less conflict (and arguing) on how much the network can support.

= The maximum throughput of the network

This proposal assumes the Segregated Witnesses Soft-fork is deployed. The maximum number of transaction the network could handle would be around 20 million transactions per day. (assuming widespread use of Segregated Witnesses in the future).

A 32MB maximum size will give much more leeway than a single 2MB increase.

= Resolving the block size conflict

- Nodes will be able to cast their vote and determine the network capacity. There will be less speculation on how much the network can support.

- Nodes will, voluntarily, compromise for China lack of bandwidth to stay on the chain with the most proof of work.

- Instead of working on multiple implementation, software developers will work on a single implementation and leave the upgrade decision to the network.

Jump to: