The facts are supporting what I am saying, Bitcoin can easily handle two megabyte blocks and smaller blocks are not better unless you think that transactions becoming more expensive and less reliable is a good thing. There is not enough space for everyone to transact regardless of the fee that is payed with such a restricted blocksize. I understand that technological growth is unlikely to continue growing exponentially, however while our technological limits can still handle it we should allow Bitcoin to continue to grow exponantially since this is what is good for Bitcoin in regards to the virtues cycle of adoption, value, security and utility.
There is nothing that would justify going for a 2 MB block size limit instead of Segwit, especially when it is so close to completion. We've talked about this a few times already. You will get the desired expansion in transaction capacity. Additionally, there should be a block size increase proposal afterwards. Nobody really knows why 'you guys' keep on rambling.
Segwit makes further blocksize increases problematic after it is implemented, you should stop pretending that you want Bitcoin to scale directly, or at the very least acknowledge that this is not Core's intention over the long run, they have made this very clear now.
Segwit is far to complex and its implementation is being rushed, this is dangerous. Increasing the blocksize is a much simpler change while it also increases transactional capacity more then Segwit does.
Segwit should be implemented as a hard fork since then its technical implementation would be superior, soft forks are an attempt to bypass the consensus mechanism, this should not be allowed. Not to mention the dangers of "anyonecanspend", this opens up an attack vector where people that have not upgraded can get their coins stolen by malicious miners. I would consider such an attack vector to be unacceptable. It is better to just allow those nodes to drop of the network like they would under a hard fork, compared to neutering them and opening up potential vulnerabilities.
There is also fee discount for certain transaction types that favor the lighting network, a seventy five percent discount actually, considering that these transactions also take up more data on the blockchain it is pretty terrible. I do not favor this type of economic planning it goes against the very ethos of Bitcoin.
The changes to the scripting language also allows Core to make radical changes to Bitcoin while bypassing the consensus mechanism even more completly, this is a very troublesome development and I would personally lose all confidence in Bitcoin once this is implemented.
Segwit is also less efficient in terms of the data that is used per transaction, Segwit actually makes Bitcoin transactions take up more data when compared to what we have today, just splitting the transaction data up into different fields does not actually make it more efficient.
As you can see I have many grievances with Segwit, I am not against Segwit in principle since fixing malleability is important, however I would favor a simplified version of Segwit, without the discount for certain transaction types and without the scripting language changes that allows Core to radically change Bitcoin by bypassing the consensus mechanism. It should also be implemented as a hard fork since this is what gives people the freedom of choice, it would also solve the other attack vector I mentioned.
It is good to also keep in mind that using the soft fork method for deploying Segwit any changes can be made, including increasing the blocksize or the supply of Bitcoin itself, turning full nodes into non validating nodes whenever such changes are made. This is an ugly hack, hard forks are far more elegant and represent the cornerstone of the very governance mechanism of Bitcoin.
