Proposal: dynamic max blocksize according to difficulty

[stuff0577]

Most of the proposal are all subjective to much further discussion and test  and all must agree with the one that is most reliable.

This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers

[99Percent]

Most of the proposal are all subjective to much further discussion and test  and all must agree with the one that is most reliable.

This is somehow relevant on the discussion. http://coin-vote.com/poll/55e8a33299baadff0a34acb7 you can share your thoughts in there. cheers

I hope you realize that polls of this type are of no use. For a hard fork to work it must be based on consensus. Consensus is a very dynamic process, it can change by the minute. First ideally core devs must arrive to it somehow (and even then miners have to accept the changes). If that doesn't happen, several implementations of the bitcoin core will appear (Bitcoin XT is the first). Then miners will start using them if they think they are superior without immediately causing a fork (as in Bitcoin XT that takes a super majority of 75% having mined with it). When the forking actually happens, the minority will be forced to join the majority unless they stubbornly refuse because of ideological concerns. In this case their blockchain will be supporting a weaker new altcoin (its price will plummet because the ones having funds on both coins will sell the weak one in favor of the strong one).

Thanks anyway.

[noobtrader]

i dont think blockchain usage always add up at the same speed with the difficulty rise.

i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1  to a max of 32.

EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation

[99Percent]

i dont think blockchain usage always add up at the same speed with the difficulty rise.

i think the more correct approach would be start at 2 then double when blockchain usage excess 75% of capacity, or halved when its less than 25% of capacity. minimum 1  to a max of 32.

EDIT : why max at 32, i heard there is a network limitation on blocksize that even XT or any implementation will need another hardfork to remove this limitation

Your approach is like BIP Upal. Unfortunately miners can manipulate the metrics involved: tx per block and sum(tx fees). So I think these types of proposals are of no use. We might as well go directly to BIP100 to see what miners really want.

Again, if miners can be coerced into only accepting tx that have appeared it the mempool somehow this might work, but I cannot think of a way to enforce this.