Title: Why would 2MB be so bad? Post by: calkob on February 27, 2017, 08:17:32 PM So after watching the Tone vays and Roger ver debate at anarchapolco, (link below) i am left with more questions than answers and one of them is this. Why would it be so bad to raise the Blocksize limit to at least 2MB + Segwit? if i have read right then something like this was actually agreed by core last year.
Just for info, i am a core supporter and run a full core node, but my loyalty lies with bitcoin and bitcoin only, i believe we should all work together to make this work. https://www.youtube.com/watch?v=XdyIJ-BUPaU Title: Re: Why would 2MB be so bad? Post by: Carlton Banks on February 27, 2017, 08:24:56 PM It wouldn't, Segwit increases the blocksize to 4MB
Title: Re: Why would 2MB be so bad? Post by: freebutcaged on February 27, 2017, 08:29:24 PM Increasing block size is a hard fork so what we need is to avoid them as possible and just do a hard fork with many other changes all at the same time=segwit.
Title: Re: Why would 2MB be so bad? Post by: franky1 on February 27, 2017, 08:40:07 PM clarity
soft and hard is simply soft: pool only vote hard: nodes and pools vote below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split 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 segwit doesnt offer 4mb of real usable space for everyone. segwit doesnt offer 4mb of real usable space instantly when activated the only way to get to 4mb is to get EVERYONE over to using segwit keys that also have extra bloated future features appended to the end of the tx in the future. such as segwit+confidential payment codes.. emphasis. its not just about getting all pools to be segwit, its not just about all nodes being segwit. its about ALL TRANSACTIONS using segwit keypairs (moving funds from old style addresses). before the benefits can be seen in full yep if 100% of users used segwit+confidential payment codes. then a segwit block will get a weight of 4mb yep if 100% of users used segwit without extra features, then segwit bocks will get a weight of ~2mb emphasis 100% of users using segwit are needed to see all the 'promises' of segwit to be achieved but if people stay with native LEAN transactions (real data for data) you wont get as many transactions and wont have the bloat. however a hardfork consensus where the REAL block limit(not weight) is increased ALL transactions get extra room and more transaction flow segwit has not solved attack vectors. its just disarmed innocent sheep segwits 'features' which segwit has been over promising as fixes of mallicious things. can be bypassed very simply.. just use native transaction types. yep just not using a segwit key means that a person can still malleate and quadratic spam a block also although segwit nodes are programmed to be upstream of the network (centralised to the pools) to avoid an issue of segwit itself (anyonecanspend attack) a malicious user can MANUALLY copy an unconfirmed segwit transaction(from segwit) and paste it into an old node and mess with it... yep that is right. they can as for "cores independance" at 40 minutes the video talks about blockstream (managed by gmaxwell) chainlabs (managed by matt corallo) lightning (managed by rusty russell) investivate those names.. and they are all funded by the same party and contracted with the same party. as for the other 100 'unpaid volunteers'. mainly spellcheckers. they are biased into working as unpaid interns hoping to get a blockstream / DCG job danng!! guy in purple admits at 55min-60min he is not an expert, not a coder, doesnt know all the details, doesnt hold or spend much bitcoin. isnt much of a bitcoin user. wow... they should have got someone better on then that guy Title: Re: Why would 2MB be so bad? Post by: Carlton Banks on February 27, 2017, 09:04:24 PM Increasing block size is a hard fork so what we need is to avoid them as possible and just do a hard fork with many other changes all at the same time=segwit. Well, increasing the base blocksize is a hardfork, but introducing new parallel block structures can be done with a softfork (Segwit does this). The new block structure (witness blocks) can't have it's limit changed though without a hardfork, it's a new addition to the consensus rules. Title: Re: Why would 2MB be so bad? Post by: Xester on February 28, 2017, 01:15:39 PM So after watching the Tone vays and Roger ver debate at anarchapolco, (link below) i am left with more questions than answers and one of them is this. Why would it be so bad to raise the Blocksize limit to at least 2MB + Segwit? if i have read right then something like this was actually agreed by core last year. Just for info, i am a core supporter and run a full core node, but my loyalty lies with bitcoin and bitcoin only, i believe we should all work together to make this work. https://www.youtube.com/watch?v=XdyIJ-BUPaU If we make decisions to solve bitcoins issue by altering bitcoin then that is not a good way to go. If we use Segwit to increase the blocksize it will surely benefit the bitcoin network but if we rely on segwit then they can control and manipulate the mining system in bitcoin. If we continue to place a non-bitcoin entity inside bitcoin soon bitcoin will no longer be bitcoin. Title: Re: Why would 2MB be so bad? Post by: szpalata on February 28, 2017, 01:23:30 PM Increasing block size is a hard fork so what we need is to avoid them as possible and just do a hard fork with many other changes all at the same time=segwit. I agree with you but what happens to the bitcoins we are holding after the hard fork? Are they still going to be valuable or will the same rate be generated for us after the hard fork? Title: Re: Why would 2MB be so bad? Post by: disconnectme on February 28, 2017, 01:24:29 PM I watched the debate also and even the one between Jonny and Roger later. For me there is nothing wrong in having 2MB but the issue here is we can get much more than 2MB with SegWit and much more with lighting. The issue on ground is more of political debate than development because I think some people felt left out of the game and want a share of the cake
Title: Re: Why would 2MB be so bad? Post by: franky1 on February 28, 2017, 01:29:26 PM I watched the debate also and even the one between Jonny and Roger later. For me there is nothing wrong in having 2MB but the issue here is we can get much more than 2MB with SegWit and much more with lighting. The issue on ground is more of political debate than development because I think some people felt left out of the game and want a share of the cake segwit does not give 2mb or 4mb straight off the boat of activation. segwit doesnt solve 100% malleability segwit doesnt solve 100% quadratics it wont solve it by having just 100% of pools using segwit it wont solve it by having 100% of nodes using segwit. the promises can only be achieved if 100% of funds are sent using segwit transactions.. which malicious people wont use segwit keys. meaning problem not solved, and tx count boost maximum expectation wont be achieved |