Why I feel a small blocksize increase should be done first and SegWit done, as soon as safely possible, secondIt is important to realize that SegWit actually is a block-size increase if you don't play semantic games. They are breaking apart the block data into two streams, both of which have to be stored on the users hard drive. The combined size of the two streams will increase the disk space requirements for full nodes.
It is important to note the hypocrisy here. For months the core party line against having a blocksize increase was because it would hurt centralization due to the increased bandwidth and disk space requirements. However, SegWit has essentially the same increased bandwidth and disk space requirements as a simple blocksize increase. It is the same data, just stored into two separate streams instead of one. Now, they are all in favor of increasing the bandwidth and disk space requirements (in the form of SegWit) but their excuse is that it can be done via a 'safe' soft fork instead of an 'evil' hard fork. The goal posts move an awful lot with these guys.
The reason to do SegWit is less about scaling and more because it is a relatively clean fix to the long standing transaction malleability problem.
The reasons not to hold up a blocksize increase for SegWit should be obvious. Remember, both approaches ARE a blocksize increase. It is just that one plays a semantic game by breaking the blocks apart into two interleaved streams of data; which adds a remarkable amount of complexity by the way.
Let's compare the two approaches.Increase the blocksize limit -A single line code change to the client
-Unlikely to break hardly any existing software anywhere or, if it does, the fix will also just be a one line code change
-Has roughly the same disk footprint requirements as SegWit
-Does nothing about transaction malleability
-Requires a hard fork
-Could be done on a much shorter time scale since the risk is extremely low and updating software extremely trivial
-Immediately provides a doubling of the transaction capacity of the entire bitcoin network as soon as it is activated.
SegWit -Fixes transaction malleability (YEAH!)
-Increases disk space requirement roughly the same as a blocksize increase would.
-It is a highly complex code change that will require a lengthy period of time to be fully vetted and tested.
-If done as a soft-fork, instead of a hard fork, it will be even more complicated and 'silently' break nearly every piece of software in the existing infrastructure
-Breaks almost all wallets, nodes, and block-explorer type apps, requiring a significant code refactor to be able to parse and correctly interpret the separate signature stream. Could cause some wallets and explorers to crash and many nodes to fail to validate fully.
-If done as a hard fork it is much, much, safer, because it won't be activated until most of the network has upgraded their software and with a substantial lead time.
-Doesn't actually achieve the transaction throughput benefit until the entire software infrastructure has switched over to using the new feature; which will be 'opt-in'.
In my opinion, we should do both, but do a 2mb blocksize increase as soon as possible and SegWit once it has been fully vetted and thoroughly tested.
Unlike the vast screaming hordes, I do not believe that hard forks are dangerous or something to be avoided. I strongly believe we need to change this mentality. The bitcoin ecosystem must be agile enough to upgrade software on a fairly regular basis; this is a basic requirement of any modern software development project.
I much prefer that SegWit be done as a hard fork, it is simply much, much, safer to do it that way. It introduces a lot of complexity and will have numerous dangerous side effects throughout the ecosystem if done 'silently' as a soft-fork.
https://www.reddit.com/r/btc/comments/3ypkhd/why_i_feel_a_small_blocksize_increase_should_be/that would be a compromise and the war could be over. everyone (except Peter Todd) can live with that.
