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.

[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.

[RustyNomad]

Not too long ago, 1 TB harddisks were unimaginable. A bit longer ago, but still quite recently, 1 GB was already *huge*.

Read last night that that Samsung has announced their new 16TB SSD so storage space will not be a problem in the near future - link: http://www.zdnet.com/article/samsung-announces-16tb-ssd/

Reading through this thread it seems like the major debate now is no longer on whether the block size has to be increased or not but rather by how much and how often. I'm no expert when it comes to this but think that it has to be dynamic in nature meaning that it has to be based on actual events/growth and not just based on our best guesses of how fast and how big blocks will grow.

[tspacepilot]

What I don't get with this whole topic about block sizes is why there's not a solution out there to dynamically increase or decrease block size based on usage.  That's pretty much what we do with everything else in the network.  Difficulty goes up and down based on how hash power there is to keep the block time constant on average.  Why wouldn't we do the same thing with the block size?  Imagine, if blocks are >95% full for 2 weeks, block size limit goes up; if blocks are <95% full on average in another two weeks, block size limit goes back down.

It seems to me that such a solution would move the discussion to what's really important, which is how full we want the blocks to be.  I know that some want fuller blocks as a way to prompt higher fees, others say we don't want long confirmation times.  Wallets are adapting to these spam attacks already to allow people to more easily set a higher or lower fee on a given transaction (even my mobile wallet has this option now).  As wallets adapt to allow users to dynamically set their fee, the other variable is the block size, we don't want the blocks to be completely full all the time (right?), so how full do we want them?  I don't know if 95% is right, but it seems like we might find more consensus around a proposal that wasn't going to arbitrarily explode block sizes if the extra space isn't really crucial.  Allowing block size limit to expand and contract with usage means we might actually have a lower block size limit for a while.

I don't know, I know that others have proposed something like this, but it seems to be the least popular of the options.  Most people seem to be either trying to send the block size limit off on some exponential increase or they are arguing for keeping the status quo.  I think a dymanic block size limit (once which can decrease as well as increase) would be the more reasonable compromise.

[Kazimir]

What I don't get with this whole topic about block sizes is why there's not a solution out there to dynamically increase or decrease block size based on usage.

Note that the conditions I mentioned (which were just an example to illustrate this line of thought) actually do provide in a way to increase the limit based on usage. Not just "increase X% per Y time".

Why wouldn't we do the same thing with the block size?

It's not directly about the block size, it's about the block size limit. I doubt if it's very useful to decrease the limit, nothing prevents people from using less block size if the need is not there (no need to decrease the limit for that). Especially if you take careful, moderate increase conditions, things shouldn't run out of hand.
Then again, it couldn't hurt either, provided you also take some lower bound restrictions in mind, to avoid mining pools deliberately keeping blocks empty to get lower and lower block size limits, thus making block size scarce, thus increasing incentive to pay higher fees.

I think we agree that a more dyamic, adaptive approach is typically better, as it can auto-correct any temporary swings.

By the way, a problem with this:

if blocks are >95% full for 2 weeks

is that a mining pool can deliberately hold off the block size increase by just inserting one small or almost empty block once every 2 weeks.

Instead I'd rather say: the next increase (or decrease, let's call it the next limit adjustment) kicks in when there have been X almost full blocks since the last adjustment.

But in the light of this:

It seems to me that such a solution would move the discussion to what's really important, which is how full we want the blocks to be.

Perhaps it would be even better if a limit adjustment takes place every 2 weeks, just like the difficulty, based on the total size of all blocks of the past two weeks. We then adjust the limit so that, assuming the past two weeks volume, we would maintain a desired average block size saturation.

I'm really curious to hear how Gavin, Mike and Gregory think about this kind of approach. I most certainly hope they'll somehow find a compromise and avoid the risk of Bitcoin getting divided in Core vs XT.

[mmeijeri]

What I don't get with this whole topic about block sizes is why there's not a solution out there to dynamically increase or decrease block size based on usage.

What is and isn't safe technically is determined in large part by the sort of connectivity people all around the world have in their homes. What is and isn't safe from an economic point of view depends in large part on how many people want to use Bitcoin. Neither of these things can be measured directly from the blockchain.

[tspacepilot]

But in the light of this:

It seems to me that such a solution would move the discussion to what's really important, which is how full we want the blocks to be.

Perhaps it would be even better if a limit adjustment takes place every 2 weeks, just like the difficulty, based on the total size of all blocks of the past two weeks. We then adjust the limit so that, assuming the past two weeks volume, we would maintain a desired average block size saturation.

I'm really curious to hear how Gavin, Mike and Gregory think about this kind of approach. I most certainly hope they'll somehow find a compromise and avoid the risk of Bitcoin getting divided in Core vs XT.

I do believe that we agree.  Except that maybe I'm a little less worried about the fragmentation than you are.   I guess I tend to think that when people get very passionate about doing things one particular way, the great thing about FOSS is that they have the freedom to go off and do it and see what happens.  If Bitcoin (or any project) is truly resilient and robust then it will survive.  If it doesn't survive (in its present form), it wasn't meant to be, I guess.  Bitcoin has already given the world a huge gift of innovation and disruption and new ways to think about money and exchange of value and trustlessness.  I think bitcoin has more to give, but only time will tell.

[SebastianJu]

Why not dropping the blocksizelimit completely since we know now that it won't lead to endless spamming?

If the spamming showed anything then that it's expensive. It only makes sense when you have a different agenda you want to prove. It might be worth as a business when you cut down costs by randomly spam, so to spread fear that a low fee might lead to being caught in a next spam attack. If some big miner tip for that cause then it might be worth it when not done constantly and with 1 MB max block size.

So we can say that with no block size limit it would not be worth it doing it, theoretically, for the reason of raising fees.

And the past has shown that advertising spam, or similar things, didn't happen on a scale that the blocks are full constantly.

So i think there is no reason anymore to fear when dropping the max blocksize limit completely now. Ok, spamming would become a bit cheaper but advertising spam would cost, because of the low amounts send. And blocksize spam would be cheaper, yes. So spamming for malicious reasons. But they would need to create much larger transactions and they would not reach anything with it. So they can drop it because it would cause costs without sense.

But even that could be confined when adding output related fees like litecoin implemented. I don't see a reason, and didn't get an answer why it is needed, that bitcoin is the only currency that charges one fee for transacting to different targets in one transaction and paying way less then with single transactions.

Maybe i'm wrong. Then educate me.

[tspacepilot]

Why not dropping the blocksizelimit completely since we know now that it won't lead to endless spamming?

If the spamming showed anything then that it's expensive. It only makes sense when you have a different agenda you want to prove. It might be worth as a business when you cut down costs by randomly spam, so to spread fear that a low fee might lead to being caught in a next spam attack. If some big miner tip for that cause then it might be worth it when not done constantly and with 1 MB max block size.

So we can say that with no block size limit it would not be worth it doing it, theoretically, for the reason of raising fees.

And the past has shown that advertising spam, or similar things, didn't happen on a scale that the blocks are full constantly.

So i think there is no reason anymore to fear when dropping the max blocksize limit completely now. Ok, spamming would become a bit cheaper but advertising spam would cost, because of the low amounts send. And blocksize spam would be cheaper, yes. So spamming for malicious reasons. But they would need to create much larger transactions and they would not reach anything with it. So they can drop it because it would cause costs without sense.

But even that could be confined when adding output related fees like litecoin implemented. I don't see a reason, and didn't get an answer why it is needed, that bitcoin is the only currency that charges one fee for transacting to different targets in one transaction and paying way less then with single transactions.

Maybe i'm wrong. Then educate me.

I think a lot of people are worried that without a blocksize limit then there's no way to predict the size of blockchain storage for full nodes.  Additionally, zero-fee transaction may be included by miners just to change the  hash of the block.  I think there are a lot of reasons why block-size limits are there.  I'm not an expert tho.

[SebastianJu]

Why not dropping the blocksizelimit completely since we know now that it won't lead to endless spamming?

If the spamming showed anything then that it's expensive. It only makes sense when you have a different agenda you want to prove. It might be worth as a business when you cut down costs by randomly spam, so to spread fear that a low fee might lead to being caught in a next spam attack. If some big miner tip for that cause then it might be worth it when not done constantly and with 1 MB max block size.

So we can say that with no block size limit it would not be worth it doing it, theoretically, for the reason of raising fees.

And the past has shown that advertising spam, or similar things, didn't happen on a scale that the blocks are full constantly.

So i think there is no reason anymore to fear when dropping the max blocksize limit completely now. Ok, spamming would become a bit cheaper but advertising spam would cost, because of the low amounts send. And blocksize spam would be cheaper, yes. So spamming for malicious reasons. But they would need to create much larger transactions and they would not reach anything with it. So they can drop it because it would cause costs without sense.

But even that could be confined when adding output related fees like litecoin implemented. I don't see a reason, and didn't get an answer why it is needed, that bitcoin is the only currency that charges one fee for transacting to different targets in one transaction and paying way less then with single transactions.

Maybe i'm wrong. Then educate me.

I think a lot of people are worried that without a blocksize limit then there's no way to predict the size of blockchain storage for full nodes.  Additionally, zero-fee transaction may be included by miners just to change the  hash of the block.  I think there are a lot of reasons why block-size limits are there.  I'm not an expert tho.

Why include zero fee transactions to change the hash? Is there an advantage from doing so?

I don't see any of these risks being valid when i see that, without spamming, the blocks aren't fully filled. So all the fears should be baseless, i think.

[tspacepilot]

Why include zero fee transactions to change the hash? Is there an advantage from doing so?

I don't see any of these risks being valid when i see that, without spamming, the blocks aren't fully filled. So all the fears should be baseless, i think.

You "mine" a block when you find a block hash that is lower than the difficulty threshold.  Hash functions are made to be such that a small change in the string you're hashing leads to an unpredictable change in the hash.  Miners are trying lots and lots of hashes (by changing the nonce) to try to find the next block faster.  Along with the nonce, you can also change other things in the block you're trying to mine such as which transactions are included.  I'm not a miner myself, so someone else here will have to tell you more.  But at least in principle, there is a motivation for miners to include various sets of transactions in a block in order to try to win the race to find the next block.  As long as the coinbase (block reward) far outstrips any transaction fees (as is currently the case), any miner would be happy to mine a block with no transactions at all simply to claim the block rewards.  There are many such empty blocks in the blockchain.

[Delek]

The compromise is to have BIP100/BIP101/BIPxxx-where-xxx-is-a-good-scalable-solution ON CORE SATOSHI CLIENT.

[Kazimir]

The compromise is to have BIP100/BIP101/BIPxxx-where-xxx-is-a-good-scalable-solution ON CORE SATOSHI CLIENT.

Eh, yes. I didn't mention this explicitly so perhaps it wasn't clear, but indeed I meant integrating a compromise in the core client, so XT can be shutdown and all Bitcoin users are on the same, one and only Bitcoin protocol again.

[SebastianJu]

Why include zero fee transactions to change the hash? Is there an advantage from doing so?

I don't see any of these risks being valid when i see that, without spamming, the blocks aren't fully filled. So all the fears should be baseless, i think.

You "mine" a block when you find a block hash that is lower than the difficulty threshold.  Hash functions are made to be such that a small change in the string you're hashing leads to an unpredictable change in the hash.  Miners are trying lots and lots of hashes (by changing the nonce) to try to find the next block faster.  Along with the nonce, you can also change other things in the block you're trying to mine such as which transactions are included.  I'm not a miner myself, so someone else here will have to tell you more.  But at least in principle, there is a motivation for miners to include various sets of transactions in a block in order to try to win the race to find the next block.  As long as the coinbase (block reward) far outstrips any transaction fees (as is currently the case), any miner would be happy to mine a block with no transactions at all simply to claim the block rewards.  There are many such empty blocks in the blockchain.

I know that it is a factor the hash is based on. But when you say that is the reason then this does not make sense to me. I mean the ASICS are calculating an enourmous amount of hashvariations by already changing one of the factors. And, like you say, the outcome is random. Changing the amount of transactions could not be done in the asic, which means it would be done by the host computer and it would be incredibly slow. It would simply be the same like trying to mine with the host computer.

So i still don't see what it would be worth for.

[tspacepilot]

Why include zero fee transactions to change the hash? Is there an advantage from doing so?

I don't see any of these risks being valid when i see that, without spamming, the blocks aren't fully filled. So all the fears should be baseless, i think.

You "mine" a block when you find a block hash that is lower than the difficulty threshold.  Hash functions are made to be such that a small change in the string you're hashing leads to an unpredictable change in the hash.  Miners are trying lots and lots of hashes (by changing the nonce) to try to find the next block faster.  Along with the nonce, you can also change other things in the block you're trying to mine such as which transactions are included.  I'm not a miner myself, so someone else here will have to tell you more.  But at least in principle, there is a motivation for miners to include various sets of transactions in a block in order to try to win the race to find the next block.  As long as the coinbase (block reward) far outstrips any transaction fees (as is currently the case), any miner would be happy to mine a block with no transactions at all simply to claim the block rewards.  There are many such empty blocks in the blockchain.

I know that it is a factor the hash is based on. But when you say that is the reason then this does not make sense to me. I mean the ASICS are calculating an enourmous amount of hashvariations by already changing one of the factors. And, like you say, the outcome is random. Changing the amount of transactions could not be done in the asic, which means it would be done by the host computer and it would be incredibly slow. It would simply be the same like trying to mine with the host computer.

So i still don't see what it would be worth for.

But in fact miners do do this.  I don't have the specific reference for you at the moment, but once a miner has iterated through all of the nonce values for a given set of transactions they start changing other stuff: the time stamp, the list of transactions to include.  I don't think we should go too much farther into it as it seems afield of the main topic here.  But I believe it's quite true that miners manipulate the number of transactions included in order to win the race to find the next block.  Even if you didn't want to look into the technical details, I think the empty blocks on the blockchain are enough to show you this.

[danielW]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

[tspacepilot]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

It looks like BIP100 is gaining some traction.  BIP100 has a dynamic block size limit that's readjusted based on miner vote every certain number of weeks.  I think it's a pretty good solution and I'm hoping that everyone will start to rally around it.  It doesn't have the exponential growth problem of BIP101 either.

@danielW: changing the hard limit of 21 million bitcoins isn't going to happen, if it does, a lot of people's confidence would be immediately shattered.  That's considered one of those hard-and-fast promises.

[SebastianJu]

Why include zero fee transactions to change the hash? Is there an advantage from doing so?

I don't see any of these risks being valid when i see that, without spamming, the blocks aren't fully filled. So all the fears should be baseless, i think.

You "mine" a block when you find a block hash that is lower than the difficulty threshold.  Hash functions are made to be such that a small change in the string you're hashing leads to an unpredictable change in the hash.  Miners are trying lots and lots of hashes (by changing the nonce) to try to find the next block faster.  Along with the nonce, you can also change other things in the block you're trying to mine such as which transactions are included.  I'm not a miner myself, so someone else here will have to tell you more.  But at least in principle, there is a motivation for miners to include various sets of transactions in a block in order to try to win the race to find the next block.  As long as the coinbase (block reward) far outstrips any transaction fees (as is currently the case), any miner would be happy to mine a block with no transactions at all simply to claim the block rewards.  There are many such empty blocks in the blockchain.

I know that it is a factor the hash is based on. But when you say that is the reason then this does not make sense to me. I mean the ASICS are calculating an enourmous amount of hashvariations by already changing one of the factors. And, like you say, the outcome is random. Changing the amount of transactions could not be done in the asic, which means it would be done by the host computer and it would be incredibly slow. It would simply be the same like trying to mine with the host computer.

So i still don't see what it would be worth for.

But in fact miners do do this.  I don't have the specific reference for you at the moment, but once a miner has iterated through all of the nonce values for a given set of transactions they start changing other stuff: the time stamp, the list of transactions to include.  I don't think we should go too much farther into it as it seems afield of the main topic here.  But I believe it's quite true that miners manipulate the number of transactions included in order to win the race to find the next block.  Even if you didn't want to look into the technical details, I think the empty blocks on the blockchain are enough to show you this.

Interesting. I never thought that the amount of possible nounces is so limited that miners have to go use these ways. Yes, then this makes sense for sure. The asics go through all nounce iterations and in the meanwhile the host computer is preparing another hash for the blocks transactions less than a transaction. So the number of nounces to check can be raised. But i really did not think that this is needed at all.

If that is really needed then it's probably because of the high speed of asics nowadays. So wouldn't we run into problems someday then when we checked all possible iterations of transactions? Though when i think about it... the transactions only needed to be sorted a bit different and you already have a new hash. So most probably there will never be a problem. This workaround will work all the time.

But you already say it too, the time stamp is a factor too, yes, i checked these things out some years ago. I guess the timestamp should be enough to make it possible running a neverending repetition of nounces. Maybe the changing of transactions is only a sideeffect of trying to get included more valuable transactions that came to the network after the first round of hashing?

But i don't think the empty blocks are proof for this practice. They are proof of the believe that empty blocks will propagate much faster than full blocks. Having an empty block finding a sufficient hash is way too random when it should come from shuffling transactions. There are way too much empty blocks to that being the reason.

[SebastianJu]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

I often read that people believe that without a block size limit we would not have high fees. But we clearly saw in the past that this is not correct. The blocks were not full all the time, not even meeting soft limit often. And still people pay a good fee. It's not that bitcoiners are a bunch of cheapskates.

Then let's double the amount of transactions by rising adoption of bitcoin and you have a solution that works.

I don't see an artificial limit needed. There is already proof from past experiences.

[danielW]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

I often read that people believe that without a block size limit we would not have high fees. But we clearly saw in the past that this is not correct. The blocks were not full all the time, not even meeting soft limit often. And still people pay a good fee. It's not that bitcoiners are a bunch of cheapskates.

Then let's double the amount of transactions by rising adoption of bitcoin and you have a solution that works.

I don't see an artificial limit needed. There is already proof from past experiences.

How much was paid in fees in the past? It was not enough to pay for securing the network if mining reward were to become negligible.

The fees were statically set, to such a small amount that most people simply could not be bothered to turn it off and were happy to donate the tiny amount.

Bitcoins security is based on proof of work, and that can not be sustained by donations. It was NEVER sustained by donations. It is and was sustained by coinbase mining reward, thats why it can function without a block size limit now.

An economic incentive will be needed in the future, and that can only come about if block size is limited.

[Was]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

Tx fees will be enough to properly incentivize the miners to secure the network in 2140. Rest assured. Perhaps instead of discarding 21 Million limit, you could add a 9th decimal place? 1/10 of a satoshi? A dime?

was

[SebastianJu]

You need some sort of limit at some point because you need restricted space so fee market can develop.

A fee market will be needed at some point, even tho its not necessary now.

Also, dynamically adjusting block size, is almost like having no block size limit. It can be gamed, and will increase with the effect of driving fees to zero.

edit: unless another way can be found of paying miners, such as discarding 21 million limit and having a small constant reward.

(also unlimited block size might lead to huge blocks and problems for network)

I often read that people believe that without a block size limit we would not have high fees. But we clearly saw in the past that this is not correct. The blocks were not full all the time, not even meeting soft limit often. And still people pay a good fee. It's not that bitcoiners are a bunch of cheapskates.

Then let's double the amount of transactions by rising adoption of bitcoin and you have a solution that works.

I don't see an artificial limit needed. There is already proof from past experiences.

How much was paid in fees in the past? It was not enough to pay for securing the network if mining reward were to become negligible.

The fees were statically set, to such a small amount that most people simply could not be bothered to turn it off and were happy to donate the tiny amount.

Bitcoins security is based on proof of work, and that can not be sustained by donations. It was NEVER sustained by donations. It is and was sustained by coinbase mining reward, thats why it can function without a block size limit now.

An economic incentive will be needed in the future, and that can only come about if block size is limited.

The thing is that satoshi wanted bitcoin to replace fiat to get people out of the hands of the banks. You can't do this with high fees.

And he created the fee system and the block halving. He said that the fees will replace the block reward step by step. And it will. But miners can't await that the bitcoin network can survive when they await that we raise the fee with each block halving. It would be instant death to bitcoin.

Saying that... it means that miners will inevitable earn less. UNTIL adoption comes into game. The more transactions the more fee. That was always the plan. And we will kill that plan when we start to think like "Miners don't earn enough, we need to raise fees." It should not matter what miners want since of course they are in it for earning money. When half of the miners drop dead because they can't be run profitable anymore then be it. Be insured that the rewards will still be way enough to secure the network. But we can't feed all miners without end. That won't work.

Unfortunately miners are the one who decide the development of bitcoin nowadays. And that might mean higher fees will come. Raising the fees with an artificial limit is somewhat unliberal. It's like a bank consortium deciding on how high the fees has to be in order to run lucrative miners. It should not work that way. Miners has to be switched off. That happened all the time. And it has to happen in the future. Imagine all the old miners still working having them held lucrative artificially... bitcoin would be dead long ago.

The question is... will greed kill bitcoin adoption or will the far outlook win and adoption will bring the fees needed in the future?

But the bitcoin network will always be secure. You should not fear that.