SegWit is not a solution for our backlog problem. Fixing the block size limit is

[TomZ]

Should SegWit activate today, it will generate the same size blocks we have today. 1MB max. It would have no positive effect whatsoever on the backlog.

This is because none of the transactions we have in the backlog are of the different type that SegWit requires. SegWit practically rewrote the ideas of what a transaction is and users need to "opt-in" to this new format. Knowing that when they do, they can only really send those new transactions to merchants and friends that also opted in. (affecting fungibility in a negative way)

So, with SegWit taking at least a month to activate and many more months to actually have any effect on which transactions the people create this will have no effect on today's mempool backlog.

On top of that, there is a maximum of around 1.6MB. That's a measly 160% of today's throughput. We got to 250000 transactions backlog because usage is up well over 160% today.

SegWit doesn't solve the our mempool backlog. However you look at it.


On the other hand, we have a simple block-size-limit fix. Miners can choose various options, but the bottom line is that whatever they choose the only client today that actually will reject > 1MB blocks is Bitcoin Core. There are a large number of clients on the network that will accept larger blocks just fine. Which includes a huge percentage of the mining community. Which means that a solution that fixes the block-size-limit would be supported with little effort. Companies need to be made aware. We at Classic asked them a year ago and most agreed 2 weeks notice is enough.

I won't suggest a rushed solution, but the reality is pretty clear. SegWit is not a solution for our backlog problem. Fixing the block size limit is.

[rogerver]

Great post Tom.

This article also seems very relevant:


https://coingeek.com/risks-segregated-w ... n-network/