Folks had requested a variant of BIP 102 that includes a small step, to avoid the moral hazard "revisit this question" issue.
This has similar properties to BIP 102 - it is not intended to handle exponential growth, nor be a for-all-time solution. It is a short term adjustment, buying time for longer term thought, modeling and experimentation with a dynamic upper limit.
Did you get a BIP # allocation?
Don't allocate numbers yourself.
I think we need an upper ceiling on any proposal we adopt, I think 8MB may be appropriate for the time being although I would prefer BIP102 in general since it seems safer.
utACK
@GamerSg Regarding 3. At 1MB/year increase, it'd take 10 years to reach 12MB block size. 10 years ago the iPhone didn't exist. 12MB + SW would mean around 5million tx/day. That's not enough even for settlement if Bitcoin was to handle even a small fraction of todays financial system.
This has similar properties to BIP 102 - it is not intended to handle exponential growth, nor be a for-all-time solution. It is a short term adjustment, buying time for longer term thought, modeling and experimentation with a dynamic upper limit.
Sorry new at this so I have no clue how to add net.h and add increase in line 47. P2P masage... Limited to 2MB.
If its a short term adjustment, why the perpetual growth?
Anyway, the tech fundamentally has O(n²) scaling, so no amount of dynamic fiddling is going to give us long term growth that's significant. We need fundamental changes for that.
On 18 December 2015 12:37:46 GMT-08:00, Jeff Garzik notifications@github.com wrote:
This has similar properties to BIP 102 - it is not intended to handle exponential growth, nor be a for-all-time solution. It is a short term adjustment, buying time for longer term thought, modeling and experimentation with a dynamic upper limit.
Reply to this email directly or view it on GitHub: #7230 (comment)
@jgarzik I have the same opinion as @petertodd. If it's not a perfect solution, then it doesn't need to "slowly" increase the block size limit. I think a fast 2-4-8 pump is more appropriate until a solid solution is designed.
In the last few months, the number of transactions jumped from around 100k per day to 200k. That's double in a few months. What if the number of transactions goes to 0.5million/day once we activate the 2Mb cap, we'll then have to revisit this temporary fix again.
To be clear, "revisiting" doesn't mean the limit can or will be changed again. This is a security parameter and we can't simply raise it at will, and may even be forced to decrease.
Any increase must come with stakeholders signing onto the concept that this is a likely one-time increase. If not theres no reason for us to release code with an increase - let a competing team do that.
On 18 December 2015 12:49:14 GMT-08:00, Abid Omar notifications@github.com wrote:
@jgarzik I have the same opinion as @petertodd. If it's not a perfect solution, then it doesn't need to "slowly" increase the block size limit. I think a fast 2-4-8 pump is more appropriate until a solid solution is designed.
In the last few months, the number of transactions jumped from around 100k per day to 200k. That's double in a few months. What if the number of transactions goes to 0.5million/day once we activate the 2Mb cap, we'll then have to revisit this temporary fix again.
Reply to this email directly or view it on GitHub: #7230 (comment)
@hellobitcoins @ydtr @expresswallet @BlockScanUK @HashDen @SREQ @dicecoins what were the results of your testing did you find any issues?
@jgarzik I think this increase is too fast if SegWit is deployed with it since SegWit basically acts as a multiplier.
@jameshilliard SegWit destroys the security of Bitcoin. Jeff already rejected it.
@BitcoinPros I think you are looking for "Concept ACK" since "ACK" implies actually testing a pull request. What about SegWit destroys the security of Bitcoin?
2Mb is better than 1Mb.
But the block size limit should be constrained ONLY by technology (that grows exponentially):
block_size_limit = base_bock_size_limit * projected_growth_rate ^ n_of_blocks_since_the_fork
Isn't it obvious that the projected_growth_rate should be greater than 1? (e.g. 1.000005)
But block size should be constrained ONLY by technology that grows exponentially:
The main problem is that there are a lot of bottlenecks that can be hard to predict. Any sort of exponential or even linear scaling can be risky if the rate is too high or if they don't have a ceiling. I prefer to be on the safe side and not schedule any increases that we aren't fairly confident we can handle in the near term and I would prefer to not have any long term scheduled increase as the future is hard to predict. I think for this proposal we need to factor in the SegWit multiplier and hard cap it at 8MB or less.
@jameshilliard: Isn't the gradual exponential increase safe enough? If it becomes obvious that there is a high risk of running into problems in 6 months or so then it would be easy to soft fork and decrease the chosen constants.
@arsenische no far from it IMO, I don't think even a linear increase is safe if it is schedule to go over what we can currently handle or are reasonably confident we can handle in the near future, anyways this PR is obviously being brigaded from reddit so I'm going to stop commenting here, if you have any more questions feel free to contact me directly.
@arsenische It's not always clearly in the miner's best interests to reduce a block size. I think today's miners would definitely go along with a soft fork to reduce the block size if they felt it was necessary, but nobody wants to reduce the throughput of Bitcoin, especially large miners who benefit from larger block sizes (because it makes it more difficult for small miners to compete).
You may need a hardfork to reduce the blocksize (which means that it won't matter if the miners upgrade or not), but that would require getting all of the exchanges and merchants on board... seems pretty unlikely. Politically speaking, it seems that block size increase is a one way journey, especially because I don't think the public would recognize a 'blocks too big' crisis even mining pools stopped existing and all that was left were a small handful of datacenter miners.
I also don't think that setting the blocksize to grow exponentially will solve the political arguments or permanently put the blocksize debate to rest. If you set the exponent too high, and blocksize outpaces technologies ability to keep up, you end up in a disaster where you are politically manoeuvring to have the blocksize decreased. If you set the exponent too small, there will be obvious gaps between the capabilities of technology and the throughput of the Bitcoin network, and we'll be right back to where we started with the ongoing debate.
That said, NACK.
The segregated witness proposal I feel is a much stronger solution, is on track for quick deployment, is a soft fork that preserves compatibility with old nodes (old nodes will be able to send money, receive money, and even receive money from segwit addresses - a point I think is lost on many), and raises the effective blocksize by nearly as much.
@petertodd: that's correct that we may be forced to decrease it, it is easy to do with a soft fork if needed.
Any increase must come with stakeholders signing onto the concept that this is a likely one-time increase. If not theres no reason for us to release code with an increase - let a competing team do that.
Quite the opposite. Artificial limitation to an arbitrary fixed number should be signed by stakeholders. Currently they are signing in favour of exponential increase. @DavidVorick : its not about politics, it is about technology. Political decisions are not supposed to be made by developers. Just keep the conservative exponential growth adequate to the growth of technology so that the costs of running a node don't increase.
PR locked and vote brigading comments deleted.
Can one of the admins verify this patch?