Would this be a reasonable compromise between Core and XT?

[Kazimir]

1. Increase max block size to 2Mb in the near future, e.g. starting at block #390000 (≈January 1st, 2016).
2. Automatically increase the limit with 50% every 52596 blocks (≈about 1 year).

And optionally:

3. Include some anti-spam fee schedule (as the default fee settings for a Bitcoin node) similar to Litecoin's, where a small additional fee is required per small output.

This would let Bitcoin grow exponentially, and grow fully automatically without requiring any forks or manual adjustments. And a 50% size limit increase per year is well within the regular growth of disk space and bandwidth for the average user, so it avoids the centralization risks that some people worry about with 8MB blocks.

Even if it's not perfect, it's still way, WAY better than Bitcoin being split into Core and XT, where neither presents a definitive solution. Eventually, 8MB or 20MB blocks is not going to be enough either.

[1714938388]

1714938388

[1714938388]

1714938388

[1714938388]

1714938388

[1714938388]

1714938388

[1714938388]

1714938388

[mmeijeri]

My purely personal opinion: 50% per year is way too much, and there needs to be a sunset clause. It's very difficult to foresee how fast bandwidth will grow more than five years out and we also don't know what bandwidth is safe as a percentage of average domestic bandwidth or median domestic bandwidth or whatever.

I think you'll easily get a consensus based on actual, realised bandwidth data supplied by reliable sources combined with observation of the network to see if there is any evidence of either increased centralisation or of the limit hampering growth.

[Kazimir]

Well, even if the block size limit would have grown with 50% per year since the beginning of Bitcoin, we would now have 13.9 MB blocks. Still less than the 20 MB that has been discussed extensively.

But sure, the numbers here are just ballpark figures, something like 33% or 25% per year, or 50% per 75,000 or 100,000 blocks or something, could do as well.

And perhaps some smart conditions, like an increase of 50% when there have been 50,000 almost full blocks since the previous limit increase (where 'almost full' means >95% of the max block size or something). This way, if the block size limit has become larger than necessary (and with 50% increments that can never suddenly be HUGE) the next increase will be delayed automatically until it actually becomes necessary.

[hexafraction]

Well, even if the block size limit would have grown with 50% per year since the beginning of Bitcoin, we would now have 13.9 MB blocks. Still less than the 20 MB that has been discussed extensively.

But sure, the numbers here are just ballpark figures, something like 33% or 25% per year, or 50% per 75,000 or 100,000 blocks or something, could do as well.

And perhaps some smart conditions, like an increase of 50% when there have been 50,000 almost full blocks since the previous limit increase (where 'almost full' means >95% of the max block size or something). This way, if the block size limit has become larger than necessary (and with 50% increments that can never suddenly be HUGE) the next increase will be delayed automatically until it actually becomes necessary.

Remember that in any situation where full blocks are used in a calculation, someone will inevitably have an incentive to stuff them. However, limiting the growth as you mention it lowers that incentive and makes this far more reasonable.

[tsoPANos]

Well this is not new, as it is a known idea for quite a while.
Your idea belongs in the dynamic blocksize limit category, where it is defined by a pre
Many people had similar ideas. I don't like that consept, as the blocksize limit would skyrocket with your formula.

[Kazimir]

Remember that in any situation where full blocks are used in a calculation, someone will inevitably have an incentive to stuff them.

Yes, that's why I suggest an additional "anti spam" measure (through fees). Having to fill 50,000 blocks with txs that actually cost money, is going to take away a whole lot of that incentive.

I don't like that consept, as the blocksize limit would skyrocket with your formula.

How's that? 50% per year at most (provided that all blocks are actually filled, by far not the case in practice) is actually way less than the average growth of disk space and bandwidth. Something that remains within the capabilities of Average Joe's laptop and home internet connection at all times, I wouldn't call that "skyrocket".

And either way, you're going to have a hard, fixed limit on the blocksize (which is eventually going to be not enough, guaranteed) or it's going to be dynamic. The latter makes more sense to me, and sounds way more durable.

Besides, I just mentioned some numbers here, to give an indication of my line of thinking (and indeed I'm sure others have thought the same before me). Of course they can be tweaked, I'd say increasing only 25% or 33% per year, conditionally (i.e. increase only kicks in only after enough filled blocks, so it could take much longer than a year) is pretty moderate.

[tsoPANos]

Remember that in any situation where full blocks are used in a calculation, someone will inevitably have an incentive to stuff them.

Yes, that's why I suggest an additional "anti spam" measure (through fees). Having to fill 50,000 blocks with txs that actually cost money, is going to take away a whole lot of that incentive.

I don't like that consept, as the blocksize limit would skyrocket with your formula.

How's that? 50% per year at most (provided that all blocks are actually filled, by far not the case in practice) is actually way less than the average growth of disk space and bandwidth. Something that remains within the capabilities of Average Joe's laptop and home internet connection at all times, I wouldn't call that "skyrocket".

And either way, you're going to have a hard, fixed limit on the blocksize (which is eventually going to be not enough, guaranteed) or it's going to be dynamic. The latter makes more sense to me, and sounds way more durable.

Besides, I just mentioned some numbers here, to give an indication of my line of thinking (and indeed I'm sure others have thought the same before me). Of course they can be tweaked, I'd say increasing only 25% or 33% per year, conditionally (i.e. increase only kicks in only after enough filled blocks, so it could take much longer than a year) is pretty moderate.

So you want 2 mb in 2016....
With your idea aplied to a math function; f(x)= 2* (1.5)^(x - 2016)
where f(x) is the block size in mb , and x is the current year, with x ≥ 2016

in 2020 we will have f(2020)= 2*(1.5)^ (2020 - 2016) = 2 * 1.5^ 4 = 2*5.0625 = 10.125 mb
In2025 we will have f(2025) = 2*(1.5)^ (2025 - 2016) = 2 * 1.5^ 9 = 2* 38.443359375 = 76.88671875 mb
In 2030 we will have f(2030) = 583.858520508 mb = 0.5 GB
In 2035 we will have f(2035) = 4433.675640106 mb = 4.4 GB

Do you think you will be able to download 4.5 GB every 10 minutes in 2035?
Per day; 4433.675640106 * 144 = 638449.292175264  mb= 63 GB per day.
675640106 * 144 * 365 = 233033991.64397136 mb = 233033 GB = 23 PB per year...
I don't know....
But for now, even 2m per minute is a lot for some countries with limited speeds.
Bitcoin is to be used by anyone, and not the wealthy economic elite.

[RustyNomad]

I'm a complete noob when it comes to this whole blocksize debate but personally feel that it should be dynamic in nature i.e. grow together with actual demand and growth.

When looking at the blocks currently being mined I see a very large percentage of blocks that are sub 500kb. In fact, the other day I looked there were only 2 out of the last 50 blocks that were over 600kb. I don't think anybody knows at which rate blocks will grow so maybe best to have some sort of dynamic increase built into core.

Something like say - Take the largest of the past 144 blocks (1 day) and add 30% to this for the new max blocksize. This only ever gets adjusted upward, never downward.

In this way the max blocksize will dynamically grow with demand and the increasing number of transactions.


Just my 0.00007576 btc

[Kazimir]

So you want 2 mb in 2016....
With your idea aplied to a math function; f(x)= 2* (1.5)^(x - 2016)
where f(x) is the block size in mb , and x is the current year, with x ≥ 2016

in 2020 we will have f(2020)= 2*(1.5)^ (2020 - 2016) = 2 * 1.5^ 4 = 2*5.0625 = 10.125 mb
In2025 we will have f(2025) = 2*(1.5)^ (2025 - 2016) = 2 * 1.5^ 9 = 2* 38.443359375 = 76.88671875 mb
In 2030 we will have f(2030) = 583.858520508 mb = 0.5 GB
In 2035 we will have f(2035) = 4433.675640106 mb = 4.4 GB

Do you think you will be able to download 4.5 GB every 10 minutes in 2035?
Per day; 4433.675640106 * 144 = 638449.292175264  mb= 63 GB per day.
675640106 * 144 * 365 = 233033991.64397136 mb = 233033 GB = 23 PB per year...
I don't know....
But for now, even 2m per minute is a lot for some countries with limited speeds.
Bitcoin is to be used by anyone, and not the wealthy economic elite.

Like I said, it doesn't necessarily have to be 50% per year, and with the full blocks condition it may take longer than a year for every next increase.

Let's say 25% increase at every 50,000 almost full blocks, and let's assume Bitcoin is continuously being used intensively, so 80% of all blocks are almost full. That would be a 25% increase every 62,500 blocks, or every 1.19 year. Assuming a switch to 2MB in 2016, that would be:

2*1.25^(4/1.19) = 4.2 MB blocks in 2020
27.6 MB blocks in 2030
180 MB blocks in 2040

Now in my opinion, this is very moderate.

Assuming 33% increase instead of 25%, again at every 62,500 blocks (and again assuming 80% of those will be full, thus triggering the increase) those numbers are 5.2 MB, 57 MB, 629 MB in 2020, 2030 and 2040 respectively. Still very moderate.

For your reference: I can already download 4.5 GB every 10 minutes today, and I have just a regular home internet connection (by far not even the fastest available). Then again I live in West Europe, obviously I understand it's not everywhere like this. But in 20 years from now, a few GB per 10 minutes isn't going to be that much of a problem for most of the online world.

[Kazimir]

I am actually curious to hear how anti-XT people think about this.

Gregory Maxwell for example, one of the smartest Bitcoin experts to walk the planet, if I'm not mistaken you're known to be against the sudden increase to 8 or even 20 MB. How would you feel about a more smooth, dynamic increase like the scheme above?

I'm worried because splitting Bitcoin into Core and XT will cause SO much confusion, trust issues, more room for speculation and misinterpretation from media, it's VERY bad for Bitcoin's reputation and will set back Bitcoin acceptance for years.

[hexafraction]

For your reference: I can already download 4.5 GB every 10 minutes today, and I have just a regular home internet connection (by far not even the fastest available). Then again I live in West Europe, obviously I understand it's not everywhere like this. But in 20 years from now, a few GB per 10 minutes isn't going to be that much of a problem for most of the online world.

I'm in an apparently highly developed suburb of a developed country and I'm nowhere close to this. However, it may be that my setup/location is an edge-case, and it may not be as bad elsewhere.

[Kazimir]

4.5 GB in 10 minutes is 7.5 MB per sec. Well, cable connections are easily 100+ or even 200+ Mbit here, glass fiber even more (especially the new ones).

Anyway, off topic, of course I agree that 4.5 GB per 10 minutes is way too much for now. Then again, we don't even necessarily need 4.5 GB blocks in 20 years from now, not even by far.

Again: something like a 25% of 33% increase after 50000 'full or almost full' blocks, will allow for a steady, moderate (not explosive) growth in block size if it's necessary, and remain constant if it's not.

[mallard]

Maybe people could vote for block size limit similar to how the gas limit was voted for with ethereum.

[Was]

 And the Fact is, the vast majority of blocks that we see are under 600kb, and until earlier this year, were artificially capped at 750kb by miners in order to further incentivize Tx fees. (make miners more $)

However, as bitcoin continues to grow, 7tx/s will not be sufficient.

I proposed a blocksize increase that followed a Fibonacci geometric sequence. So the next max block size would be 2MB, and the next after that, 3MB, and the next, 5MB, and then 8MB and so on.

I think the best way for us to handle this issue is to implement this geometric block-size sequence into our clients and allow the block size to remain at 1MB until the last 144 Blocks are over 900kb. At least then our software will be prepared, and nothing changes until it needs to.

[hexafraction]

And the Fact is, the vast majority of blocks that we see are under 600kb, and until earlier this year, were artificially capped at 750kb by miners in order to further incentivize Tx fees. (make miners more $)

However, as bitcoin continues to grow, 7tx/s will not be sufficient.

I proposed a blocksize increase that followed a Fibonacci geometric sequence. So the next max block size would be 2MB, and the next after that, 3MB, and the next, 5MB, and then 8MB and so on.

I think the best way for us to handle this issue is to implement this geometric block-size sequence into our clients and allow the block size to remain at 1MB until the last 144 Blocks are over 900kb. At least then our software will be prepared, and nothing changes until it needs to.

What specific benefit does a growth by a percentage converging to 61.80339887% have, over other proposals such as 33% or 50%? Geometric at 1.618 seems a bit excessive.

[Was]

It will bring us to 2MB, then 3MB, then 5MB, THEN 8MB... You think it's excessive, but you don't seem to realize exactly how many transactions bitcoin may one day handle.

Gradually, and only when it's necessary. Rather than on irrelevant time intervals.
Check my post.

[hexafraction]

It will bring us to 2MB, then 3MB, then 5MB, THEN 8MB... You think it's excessive, but you don't seem to realize exactly how many transactions bitcoin may one day handle.

Gradually, and only when it's necessary. Rather than on irrelevant time intervals.
Check my post.

Yes, I was working on the understanding that it's gradual and only when necessary. However, I don't understand why you want a FIBONACCI sequence, and not some other geometric growth as needed. You haven't justified that specific point one bit.

[Kazimir]

It will bring us to 2MB, then 3MB, then 5MB, THEN 8MB... You think it's excessive, but you don't seem to realize exactly how many transactions bitcoin may one day handle.

Increasing with 61% at a time is a bit excessive, not gradual.

And increasing after 144 blocks (under certain conditions) is definitely excessive. It would take a spammer one day to induce the next increase, that's reasonably easy to pull off.

I'd rather see a somewhat less steep increase, like 25% at a time, and not too fast either. When it turns out to be necessary for a longer period of time (way longer than one day) raising it 25% should support enough growth.

Anyway, let's not dwindle too much on the specific numbers.

Does anybody not agree that this would be a good, solid, sustainable way to solve the block size issue: (at least better than to suddenly increase it to 8MB or 20MB, or keep it at 1MB)

• increase the block size limit with X% when a condition is met (e.g. there have been at least Y almost full blocks since the last size increase). 'Almost full' means something like its size being ≥90% of the current limit.

Personally, I think X=25~33 and Y=25000~50000 seem like reasonable values, but let's focus on the overall model first.

[lottery248]

i would say the block size should be doubled per 2 years, and the maximum would 256 mb, based on storage speed factor.
even though if we could afford 1 Th HDD w/ $20 in 2020, every 4096 blocks would need another HDD again. that's doesn't at all qualify the sustainable development. not only this, merchants may even increase the price of HDD, due to the excessive demand of storage, leading to unfairness distribution of storage.
i don't wanna see the electric wastage with bitcoin is higher than what government consume, we don't want a currency which wastes of energy more than what fiats does.
we want a decentralised currency, but we still need  to consider about the sustainable development in order to take the bitcoin to the top.

8 gb per block would be ridiculous for most of the newbies if they use the full node wallet.
not even me could afford such a large storage for blockchain, please consider about the newbies, majority of them would not be able to use full node wallet in the future.
i have no choice but have to use online wallet or the wallet without requiring synchronisation of blockchain to prevent the crash of my PC.

basically, bitcoin XT is centralising the full node users, forcing most of the people to use wallet which doesn't require the blockchain synchronisation, susceptible to a 51% attacks.

[Jace]

i would say the block size should be doubled per 2 years

Why doubled? (seems like a large step)
And why per 2 years (seems like a long period to adjust) instead of doing so adaptively, according to current block size usage?

and the maximum would 256 mb

"640 KB should be enough for everyone"

even though if we could afford 1 Th HDD w/ $20 in 2020, every 4096 blocks would need another HDD again. that's doesn't at all qualify the sustainable development.

Not too long ago, 1 TB harddisks were unimaginable. A bit longer ago, but still quite recently, 1 GB was already *huge*. Storage space availability grows exponentially, as does bandwidth.

8 gb per block would be ridiculous for most of the newbies if they use the full node wallet.

8GB blocks sounds ridiculously huge today, but 1 MB blocks would have sounds ridiculously huge 15-20 years ago.
There's no saying how futile a measly 8GB will be (in terms of either storage or data traffic) in 20-30 years from now.

Don't get too stuck up on the numbers. I hope the core devs can agree on a sustainable growth model, at least for the time being, rather than forcing Bitcoin to be split in Core and XT.