#Blocksize Survey

[jonald_fyookball]

Even when we acknowledge your view that decentralisation is still an important aspect and we shouldn't go too crazy with the blocksize, you still won't move an inch.

Still? My belief it's always an important aspect. Or did I misinterpret you?

I get the impression at times they feel that anyone with a view supporting larger blocks doesn't care about jeopardising decentralisation.  Like we've somehow forgotten that it's important.  That's why they can only see it as an "attack", they genuinely believe we don't understand the importance of decentralisation.  We do.  But there are valid concerns about capacity and it's vital we get the balance right, so we propose smaller increases, or dynamic increases and decreases, or letting the miners choose, but apparently none of these are viable options to the handful of "asset class" militants who reject everything out of hand.  It appears as though the only option they're willing to allow is "GTFO my chain, peasant".  So what's the point in trying to engage with them?  If they want a blockchain all to themselves, that's exactly what they're going to get when everyone else leaves them behind.

Perhaps you can explain the centralization risks as many of us who want bigger blocks think the fears are exaggerated.

For example, the storage space of the entire blockchain...Last I heard the pruned ledger was only 1 gig.

[bambou]

In the end, even the small poll up above clearly shows there is no consensus about it.

Hence, bitcoin stays as it is.

Forkers are welcome to fork out and enjoy their blindful life within some cheap tipping altchain.

But there is no need to POW it, litecoin or ripple would do the work perfectly.

[brg444]

Even when we acknowledge your view that decentralisation is still an important aspect and we shouldn't go too crazy with the blocksize, you still won't move an inch.

Still? My belief it's always an important aspect. Or did I misinterpret you?

I get the impression at times they feel that anyone with a view supporting larger blocks doesn't care about jeopardising decentralisation.  Like we've somehow forgotten that it's important.  That's why they can only see it as an "attack", they genuinely believe we don't understand the importance of decentralisation.  We do.  But there are valid concerns about capacity and it's vital we get the balance right, so we propose smaller increases, or dynamic increases and decreases, or letting the miners choose, but apparently none of these are viable options to the handful of "asset class" militants who reject everything out of hand.  It appears as though the only option they're willing to allow is "GTFO my chain, peasant".  So what's the point in trying to engage with them?  If they want a blockchain all to themselves, that's exactly what they're going to get when everyone else leaves them behind.

Perhaps you can explain the centralization risks as many of us who want bigger blocks think the fears are exaggerated.

For example, the storage space of the entire blockchain...Last I heard the prunable ledger was only 1 gig.

A prunable ledger is useless as it does nothing but relay transactions. They do not help to keep the ledger decentralized.

The problem starts with a precipitation of miner centralization brought by a screwed incentive which now enables the biggest, most connected ones to start mining bigger blocks at a rate the smaller ones could not keep up with. The real issue though is the impact it has on the nodes, who are not rewarded btw. This is where the "tragedy of the commons" plays out. As miners are incentivized to fill up their blocks regular nodes will be wiped off the map as only corporate set ups could service the appetite of the miners.

That is how Bitcoin becomes "captured" by corporate interests as they grab control over its nodes governance.

[DooMAD]

There are perfectly sensible, technical reasons to believe it is absolutely essential to keep the max block size reasonably close to the network actual average demand. Whether that is done through a flex cap or a fixed schedule it remains that we need to be absolutely conservation as we err in unknown territories.

More importantly, hitting or filling the blocks are absolutely not a bad thing and would likely develop into an healthy fee market. Obviously we cannot confirm this yet but I guess maybe we'll see next week? It is imperative that we get this right. I'm sure you have observed how contentious the hard fork is at this stage in Bitcoin's growth, it may be our last chance to arrive to consensus on one.

Finally we're getting somewhere.  So you're not opposed to a flexible cap based on demand as long as it's handled conservatively?  Was that really so difficult?  Why couldn't you just say that a few weeks ago?  The phrase "blood from a stone" comes to mind.  Obviously you couldn't say it without throwing in some conspiracy guff and once again insinuating Gavin is the devil, but hey, it's still progress.

[brg444]

There are perfectly sensible, technical reasons to believe it is absolutely essential to keep the max block size reasonably close to the network actual average demand. Whether that is done through a flex cap or a fixed schedule it remains that we need to be absolutely conservation as we err in unknown territories.

More importantly, hitting or filling the blocks are absolutely not a bad thing and would likely develop into an healthy fee market. Obviously we cannot confirm this yet but I guess maybe we'll see next week? It is imperative that we get this right. I'm sure you have observed how contentious the hard fork is at this stage in Bitcoin's growth, it may be our last chance to arrive to consensus on one.

Finally we're getting somewhere.  So you're not opposed to a flexible cap based on demand as long as it's handled conservatively?  Was that really so difficult?  Why couldn't you just say that a few weeks ago?  The phrase "blood from a stone" comes to mind.  Obviously you couldn't say it without throwing in some conspiracy guff and once again insinuating Gavin is the devil, but hey, it's still progress.

Let me insist I'd much rather we keep current blocksize for at least next year.

[DooMAD]

There are perfectly sensible, technical reasons to believe it is absolutely essential to keep the max block size reasonably close to the network actual average demand. Whether that is done through a flex cap or a fixed schedule it remains that we need to be absolutely conservation as we err in unknown territories.

More importantly, hitting or filling the blocks are absolutely not a bad thing and would likely develop into an healthy fee market. Obviously we cannot confirm this yet but I guess maybe we'll see next week? It is imperative that we get this right. I'm sure you have observed how contentious the hard fork is at this stage in Bitcoin's growth, it may be our last chance to arrive to consensus on one.

Finally we're getting somewhere.  So you're not opposed to a flexible cap based on demand as long as it's handled conservatively?  Was that really so difficult?  Why couldn't you just say that a few weeks ago?  The phrase "blood from a stone" comes to mind.  Obviously you couldn't say it without throwing in some conspiracy guff and once again insinuating Gavin is the devil, but hey, it's still progress.

Let me insist I'd much rather we keep current blocksize for at least next year.

Well I wouldn't want you to make it too easy.  We'll call it slow progress, then.  Still counting it as a win. 

[poeEDgar]

There are perfectly sensible, technical reasons to believe it is absolutely essential to keep the max block size reasonably close to the network actual average demand. Whether that is done through a flex cap or a fixed schedule it remains that we need to be absolutely conservation as we err in unknown territories.

More importantly, hitting or filling the blocks are absolutely not a bad thing and would likely develop into an healthy fee market. Obviously we cannot confirm this yet but I guess maybe we'll see next week? It is imperative that we get this right. I'm sure you have observed how contentious the hard fork is at this stage in Bitcoin's growth, it may be our last chance to arrive to consensus on one.

Finally we're getting somewhere.  So you're not opposed to a flexible cap based on demand as long as it's handled conservatively?  Was that really so difficult?  Why couldn't you just say that a few weeks ago?  The phrase "blood from a stone" comes to mind.  Obviously you couldn't say it without throwing in some conspiracy guff and once again insinuating Gavin is the devil, but hey, it's still progress.

A lot of us who are here arguing against BIP101 are not staunchly opposed to increasing the limit > 1MB. We just think that BIP101 is a very irresponsible way to implement it.

[Hugroll]

There are perfectly sensible, technical reasons to believe it is absolutely essential to keep the max block size reasonably close to the network actual average demand. Whether that is done through a flex cap or a fixed schedule it remains that we need to be absolutely conservation as we err in unknown territories.

More importantly, hitting or filling the blocks are absolutely not a bad thing and would likely develop into an healthy fee market. Obviously we cannot confirm this yet but I guess maybe we'll see next week? It is imperative that we get this right. I'm sure you have observed how contentious the hard fork is at this stage in Bitcoin's growth, it may be our last chance to arrive to consensus on one.

Finally we're getting somewhere.  So you're not opposed to a flexible cap based on demand as long as it's handled conservatively?  Was that really so difficult?  Why couldn't you just say that a few weeks ago?  The phrase "blood from a stone" comes to mind.  Obviously you couldn't say it without throwing in some conspiracy guff and once again insinuating Gavin is the devil, but hey, it's still progress.

A lot of us who are here arguing against BIP101 are not staunchly opposed to increasing the limit > 1MB. We just think that BIP101 is a very irresponsible way to implement it.

exactly, the limit increase doesn't seem like a bad idea to me.

[Lauda]

We just think that BIP101 is a very irresponsible way to implement it.

Irresponsible, dangerous and risky. If we are going to do it, then do it right. Letting Bitcoin be potentially harmed by someones prediction of technical growth is not what I would like to see.

A prunable ledger is useless as it does nothing but relay transactions. They do not help to keep the ledger decentralized.

This is partially correct. Just because pruning has not been fully implemented in Core, that does not mean that it is not going to happen.

Let me insist I'd much rather we keep current blocksize for at least next year.

That would be okay if there was no halving. We do not currently know what is going to happen with the number of transactions. What if it increases 5-10x just after the halving (this is just a example; nothing might happen as well)?

[hdbuck]

BIP000: https://www.reddit.com/r/Bitcoin/comments/3jhwi3/i_support_

[brg444]

What if it increases 5-10x just after the halving (this is just a example; nothing might happen as well)?

I don't want any decision done based on such speculation.

[DooMAD]

Upal's dynamic blocksize proposal has now been assigned a BIP number, BIP106:  https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki

It already has advantages that many want to see in an "ideal" solution.  It's algorithmic.  It can lower the blocksize as well as raise it if need be, so it adapts to the load the network is bearing.  It would likely encourage fee markets in a more subtle and natural manner than any artificial "blunt-force" caps.  It doesn't grant too much power to the miners, unlike BIP100.  Unlike BIP101 where the size would only be altered every two years, this would alter it every two weeks, so it would be more nimble and adapt more quickly to both surges and lulls in traffic.

However, there are concerns raised with potential gaming of the system and manipulating the size by pushing extra transactions.  Doubling may be excessive, so a lower percentage may need to be considered.  It should also be noted that BIP106 only considers the demand for block space and doesn't take miners' resources into consideration, which could potentially impact decentralisation if not kept in check (but again, changing the doubling part to a lower percentage would help in this regard).

What other suggestions, considerations and improvements could be made to this proposal to make it more appealing to a larger majority?

[Lauda]

I don't want any decision done based on such speculation.

Finally someone else agrees with me that we should not be basing the implementation/solution on speculation. This is exactly what Gavin has done and it is way too risky. We can not know what will happen in the future, nor will the past trends continue.

However, there are concerns raised with potential gaming of the system and manipulating the size by pushing extra transactions.  Doubling may be excessive, so a lower percentage may need to be considered.  It should also be noted that BIP106 only considers the demand for block space and doesn't take miners' resources into consideration, which could potentially impact decentralisation if not kept in check (but again, changing the doubling part to a lower percentage would help in this regard).

I concur. The main thing that bothers me is that instant doubling and halving. I think that this is way too much especially in the long run. Going from 60 to 120 MB blocks seems like way too much. If a lower percentage is to be used then this proposal would be much better.
There's also BIP105 now, and it proposes a maximum 10% increase or decrease every 2016 blocks.

[DooMAD]

However, there are concerns raised with potential gaming of the system and manipulating the size by pushing extra transactions.  Doubling may be excessive, so a lower percentage may need to be considered.  It should also be noted that BIP106 only considers the demand for block space and doesn't take miners' resources into consideration, which could potentially impact decentralisation if not kept in check (but again, changing the doubling part to a lower percentage would help in this regard).

I concur. The main thing that bothers me is that instant doubling and halving. I think that this is way too much especially in the long run. Going from 60 to 120 MB blocks seems like way too much. If a lower percentage is to be used then this proposal would be much better.
There's also BIP105 now, and it proposes a maximum 10% increase or decrease every 2016 blocks.

So if we further alter juiceayres' amendment:

Code:

If more than 50% of block's size, found in the first 144 of the last difficulty period, is more than 90% MaxBlockSize
    MaxBlockSize = MaxBlockSize +12.5% 
    Limit = +12.5% MaxBlockSize_last_1008

Else if more than 90% of block's size, found in the first 144 of the last difficulty period, is less than 50% MaxBlockSize
    MaxBlockSize = MaxBlockSize -12.5%
    Limit = -12.5% MaxBlockSize_last_1008

Else
    Keep the same MaxBlockSize

This would alter the blocksize daily if required, but the maximum increase or decrease per week would be 12.5%

Is that something that would appeal to people on both sides of the fence?

[RoadTrain]

If I understand correctly, shrinking blocksizes can be much more easily gamed by miners, as it requires only 10%+ of hashpower to prevent blocksizes from shrinking.

[DooMAD]

If I understand correctly, shrinking blocksizes can be much more easily gamed by miners, as it requires only 10%+ of hashpower to prevent blocksizes from shrinking.

It's certainly possible, but if they want to collect a greater quantity of fees, ultimately, keeping blocks deliberately small won't in their best interests.  Diminishing block rewards will naturally incentivise miners to produce larger blocks over time (providing they're significantly filled to trigger the increase).  In theory, this should garner the best of both worlds.  Not an exponential increase, but still room for growth.  Not a blunt-force cap, but a dynamic threshold that reacts to demand.

[flix]

BIP106:

BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac

+===Proposal 1 : Depending only on previous block size calculation===
+
+  If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+      Double MaxBlockSize
+  Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+      Half MaxBlockSize
+  Else
+      Keep the same MaxBlockSize

[DooMAD]

BIP106:

BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac

+===Proposal 1 : Depending only on previous block size calculation===
+
+  If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
+      Double MaxBlockSize
+  Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
+      Half MaxBlockSize
+  Else
+      Keep the same MaxBlockSize

Yes, flix, that's what the previous five posts in the thread were speaking in reference to.     (plus some BIP105 and a possible middle ground between the two of them) 

I like BIP106, but feel that at present, it would attract the same kind of vehement opposition BIP101 is receiving, as doubling/halving the blocksize may prove excessive.  So some have suggested toning it down a smidgen to avoid frightening potential support away and provide greater potential for a compromise to be reached.

[flix]

Yes, flix, that's what the previous five posts in the thread were speaking in reference to. 

oops... I'll remind myself to read before posting!   

[RoadTrain]

If I understand correctly, shrinking blocksizes can be much more easily gamed by miners, as it requires only 10%+ of hashpower to prevent blocksizes from shrinking.

It's certainly possible, but if they want to collect a greater quantity of fees, ultimately, keeping blocks deliberately small won't in their best interests.  Diminishing block rewards will naturally incentivise miners to produce larger blocks over time (providing they're significantly filled to trigger the increase).  In theory, this should garner the best of both worlds.  Not an exponential increase, but still room for growth.  Not a blunt-force cap, but a dynamic threshold that reacts to demand.

I'm talking about shrinking blocksizes, not keeping blocks small -- a pool with 10% of hashpower can prevent any shrinkage, i.e. keeping blocksize limit unreasonably high, so the supposed algorithm isn't sound. I'm not saying that it would be rational, just pointing this out.