Quote from: marcus_of_augustus on December 02, 2015, 01:42:28 AM

Quote from: Cconvert2G36 on December 02, 2015, 12:22:30 AM

https://bitcoinmagazine.com/articles/bitcoin-mining-pool-f-pool-discus-fish-maintains-bip-not-an-option-1449003767

"On the Bitcoin development mailing list, Chun recently suggested raising the maximum block size in accordance with the block halving. As such, the block-size limit would be raised to 2 megabytes as soon as possible, followed by an increase to 4 megabytes halfway through 2016, up to 32 megabytes by 2028."

Quote from: Cconvert2G36 on November 18, 2015, 11:37:56 PM

4MB max in 2016, doubling at the halvings. (2MB would/could/should have been the limit at the drop to 25btc block rewards.)

Growth in the max could be halted or slowed by soft fork if alternative scaling solutions present themselves and are proven to be both functional and desired by the market.

Code:

Max Blocksize Block Reward Year(~) Native TPS(~)
1MB 50 2009 3
2MB 25 2013 6
4MB 12.5 2016 12
8MB 6.25 2019 24
16MB 3.125 2022 48
32MB 1.5625 2026 96
64MB 0.78125 2029 192
128MB 0.390625 2033 384
256MB 0.1953125 2037 768
512MB 0.09765625 2041 1536

There's something nice about the available space in a block for fee paying txs doubling at the same time the reward is cut.

This could cut either way and one is disastrous for security:

1) If the block space is being fully-utilised and the fee-market is producing optimal returns based on full blocks then doubling the block size at the same time as halving the reward would be a double whammy for miners as more blockspace will lead to a drop off in fees at the same time reward is halved.

2) the other way is speculative but what big-blockers use as an argument, block size doubles and miraculously fees do not drop but the number of transactions goes up so sweet nirvana, bigger blocks brings in more total fees.

Lots more here to think about than simply making blocks bigger. Fees need to pay increasingly for security out into the future and blocks cannot grow faster than the technological progress that can accommodate them on a sufficiently decentralised network. It seems there is probably an optimum blocksize for bringing in the maximal total fees and another optimum blocksize that maximises network decentralisation. Those two criteria are not necessarily compatible and neither of those two criteria maybe fully observable variables given the input metric data internally available to the network (in a control theoretic system analysis).

First the fee market. People already pay fees, and blocks are 60-70%(?) or so to capacity on avg. (fudging a bit for reward only blocks). They will continue to do so with blocks smaller than max, as seen today. More of them, more fees. It really comes down to whether we force the fee market artificially now (soon), or let the miners set the prices for their services. Doing nothing, staying at 1MB max, is doing something, implementing an artificial fee market at 25 or 12.5 btc per block. This is a change from the state of the network up until now. And too early imo.

Impact on the decentralized node network is a valid concern, and I'm not dismissing it, that's why I'm liking this much more conservative proposal. It seems the reward schedule looks like it does, front loaded, in order to act as a sort of launching subsidy. This allows the network to grow faster than if all mining costs were placed directly on the user, ~$5 or more per tx. This can't have been an afterthought on satoshi's part, to me, it means grow as fast as possible (while maintaining a sufficiently wide attack surface) into the 2020's.

4MB blocks going towards 2020 seems like it's leaning towards protecting decentralization vs growth at all costs. And it's a number I bet most BIP101 fans would find absurdly small. As polarized as this debate has been, I think the winning proposal should be the one that equalizes displeasure between the XT-Unlimited and 1MB4EVA camps. Doubling max block size in tandem with halvings mimics and compliments the simplicity and predictability of the reward schedule.