Topic: Why would 2MB be so bad? (Read 497 times)

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

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

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?

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.

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.

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

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.

It wouldn't, Segwit increases the blocksize to 4MB

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