jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
|
September 03, 2015, 10:32:56 PM Last edit: September 03, 2015, 11:22:24 PM by 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
|
|
September 03, 2015, 10:33:41 PM |
|
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.
|
Non inultus premor
|
|
|
brg444
|
|
September 03, 2015, 10:43:50 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
DooMAD
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 03, 2015, 11:19:05 PM |
|
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
|
|
September 03, 2015, 11:22:20 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
DooMAD
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 03, 2015, 11:27:47 PM |
|
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
|
|
September 04, 2015, 12:48:20 AM |
|
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.
|
I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.
|
|
|
Hugroll
|
|
September 04, 2015, 12:52:22 AM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
September 04, 2015, 09:37:12 AM |
|
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)?
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
hdbuck
Legendary
Offline
Activity: 1260
Merit: 1002
|
|
September 04, 2015, 10:23:58 AM |
|
|
|
|
|
brg444
|
|
September 04, 2015, 03:08:48 PM |
|
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.
|
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
DooMAD
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 05, 2015, 10:15:09 PM |
|
Upal's dynamic blocksize proposal has now been assigned a BIP number, BIP106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawikiIt 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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
September 06, 2015, 11:03:18 AM |
|
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.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
DooMAD
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 06, 2015, 11:36:56 AM Last edit: September 16, 2015, 03:11:31 PM by 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: 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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
September 06, 2015, 11:47:07 AM |
|
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
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 06, 2015, 12:05:22 PM |
|
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 (OP)
Legendary
Offline
Activity: 1227
Merit: 1000
|
|
September 06, 2015, 05:29:30 PM |
|
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
Legendary
Offline
Activity: 3934
Merit: 3190
Leave no FUD unchallenged
|
|
September 06, 2015, 06:41:37 PM |
|
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 (OP)
Legendary
Offline
Activity: 1227
Merit: 1000
|
|
September 06, 2015, 08:12:59 PM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
September 06, 2015, 08:15:39 PM |
|
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.
|
|
|
|
|