Topic: #Blocksize Survey - page 7. (Read 16117 times)
hey, i dont really follow the bitcoin background updates. i just wanted to know if theres a proposal that supports no change (the limit staying at 1mb). and is that proposal popular. i don't support the " no changers",just wanted to know if theres a chance that they will prevail, cuz imo thats pretty bad for bitcoin.
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.
Okay, we can work on that part, so how do we make it more sound? The rather frustrating pattern with these discussions is that people are very quick to point out what might not work, but very slow to offer a solution as to what might work.
Quote
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!
Easily done. I find myself getting the threads mixed up as there's several dozen of them now.
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.
Okay, we can work on that part, so how do we make it more sound? The rather frustrating pattern with these discussions is that people are very quick to point out what might not work, but very slow to offer a solution as to what might work.
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.
Quote
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!
BIP106:
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
Quote
+===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
+
+ 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.
BIP106:
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap
https://github.com/bitcoin/bips/commit/2e0d3412546e28da19c8ab6cc0056fc05542acac
Quote
+===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
+
+ 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
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.
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.
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?
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.
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?
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?
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.
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)? 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Jump to: