|
Title: Would you support a hard fork to increase block size by 0.2MB? Post by: Quantus on February 24, 2017, 02:47:14 PM Would you support a hard fork to increase block size by 0.2MB?
For a total size of 1.2MB. Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: franky1 on February 24, 2017, 02:57:32 PM knowing the mempool is usually always filled with atleast 2000-4000tx's minimum... 0.2 extra is stupidly low. and is not even going to make a noticable difference.
why bother programming an implementation and spending time waiting for loads of people to download it to get to a NODE consensus of high majority for a one time 0.2mb boost. if there is going to be a new node consensus required implementation release. it needs to be variable (dynamic) that way we are not relying on any dev's to spoon feed stupid amounts. but where the network can find an agreement on the amount, due to nodes having the ability to adjust amounts independantly and flag what they can cope with. and having consensus move the network forward naturally by the community (node consensus).. not dev overlords P.S i presume this topic is just to bait a narative that by mentioning a stupidly low amount the OP will twist it to say 'oh look lots of people are saying no' where by the OP will then say 'looks like the community is happy to keep it at 1mb'.. but the debate is not about keeping it down. its about HOW to make it naturally grow without dev overlord control Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: Catmony on February 24, 2017, 03:04:40 PM Would you support a hard fork to increase block size by 0.2MB? 1.2 MB will be not enough for sure we have to think about 3-4 MB atleast because there are really so much transactions within 10 minute period right now (3-5 transactions per second). For a total size of 1.2MB. Hard fork is not a good solution, it can split the bitcoin network into two or more just like ETH and ETC. Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: NeuroticFish on February 24, 2017, 03:09:34 PM Would you support a hard fork to increase block size by 0.2MB? For a total size of 1.2MB. Since I don't have (yet?) a full node, whatever I'd say will not actually count. However... 0.2MB extra? Sure, why not? But then in a month or so we will have to make another 0.2 fork and then 10 more until the pressure is relieved. From what I know hard forks may affect the price and make the merchants unhappy. And Ethereum is good for something: to remind us the hard fork is something that needs carefully prepared - politically, PR-wise, call it as you wish. Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: LittleBitFunny on February 24, 2017, 03:15:35 PM The fundamental problem with Bitcoin here isn't the exact block size, it's about the fact that it's fixed. There are several points in Bitcoin's history here the block size should have been higher to handle the high number of transactions, including now, and there were also several points when the block size didn't need to be so high. If developers need to react every time there's a change in the number of transactions taking place on the bitcoin network, then there's a problem with the system because they will always be too slow and there will always be too much debate taking place.
It also seems like you're going to twist this topic for your own opinions, as if people are okay with it being at 1mb. Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: franky1 on February 24, 2017, 03:32:37 PM And Ethereum is good for something: to remind us the hard fork is something that needs carefully prepared - politically, PR-wise, call it as you wish. Hard fork is not a good solution, it can split the bitcoin network into two or more just like ETH and ETC. a hard fork is not the exact same as ethereum.. even soft forks can cause intentional splits. ethereum was an intentional split to save repeating myself in short: soft=only pools vote hard=nodes and pools vote. then there are sub categories of good or bad of each softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains if you want to talk about the ethereum style of for. that was a hard BILATERAL(intentional) split. but also remember there is code in bip 9 to allow a soft bilateral(intentional) split too. yep gmaxwell confirms even in a soft(pool only) event bilateral splits can happen too If there is some reason when the users of Bitcoin would rather have it activate at 90% (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation. and when active. segwit pools will still actively ignore non-segwit pools https://bitcoincore.org/en/2016/10/28/segwit-costs/ Quote Miners could simply use software that does not recognise segwit rules (such as earlier versions of Bitcoin Core) to mine blocks on top of a chain that has activated segwit. This would be a hard-fork as far as segwit-aware software is concerned, and those blocks would consequently be ignored by Bitcoin users using segwit-aware validating nodes. If there are sufficiently many users using segwit nodes, such a hard-fork would be no more effective than introducing a new alt coin. this is them talking about doing bilateral splits in a soft (pool only) flagging event.ethereum was not consensus. it was bilateral. --oppose-dao-fork (forcing nodes to BAN opposing nodes and avoid consensus) Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: deisik on February 24, 2017, 03:43:54 PM Would you support a hard fork to increase block size by 0.2MB? For a total size of 1.2MB. Why do you ask this? There is no reason to increase the block size just by 0.2Mb. Some miners are still using blocks only up to 700Kb in size (the old value as I got it), and some rogue miners deliberately don't include any transactions at all in the blocks they find. Ultimately, increasing the block size can be only an interim solution before proceeding to a new paradigm based on off-chain transactions. This is the way to go, not stupidly increasing the block size indefinitely, either by 0.2 Mb or whatever Title: Re: Would you support a hard fork to increase block size by 0.2MB? Post by: Carlsen on February 24, 2017, 03:56:10 PM And Ethereum is good for something: to remind us the hard fork is something that needs carefully prepared - politically, PR-wise, call it as you wish. Hard fork is not a good solution, it can split the bitcoin network into two or more just like ETH and ETC. a hard fork is not the exact same as ethereum.. even soft forks can cause intentional splits. ethereum was an intentional split to save repeating myself in short: soft=only pools vote hard=nodes and pools vote. then there are sub categories of good or bad of each softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains if you want to talk about the ethereum style of for. that was a hard BILATERAL(intentional) split. but also remember there is code in bip 9 to allow a soft bilateral(intentional) split too. yep gmaxwell confirms even in a soft(pool only) event bilateral splits can happen too If there is some reason when the users of Bitcoin would rather have it activate at 90% (e.g. lets just imagine some altcoin publicly raised money to block an important improvement to Bitcoin) then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation. and when active. segwit pools will still actively ignore non-segwit pools https://bitcoincore.org/en/2016/10/28/segwit-costs/ Quote Miners could simply use software that does not recognise segwit rules (such as earlier versions of Bitcoin Core) to mine blocks on top of a chain that has activated segwit. This would be a hard-fork as far as segwit-aware software is concerned, and those blocks would consequently be ignored by Bitcoin users using segwit-aware validating nodes. If there are sufficiently many users using segwit nodes, such a hard-fork would be no more effective than introducing a new alt coin. this is them talking about doing bilateral splits in a soft (pool only) flagging event.ethereum was not consensus. it was bilateral. --oppose-dao-fork (forcing nodes to BAN opposing nodes and avoid consensus) I really was not aware of that. So, is there a way to make the fork consensus and avoid a bilateral split? The way I understand it now is, that the outcome of two permanent chains would have to be put into the source code and is not a matter of agreement or disagreement. |