From what I read segwit sounds like a reasonable solution to what seems like a very real practical issue with bitcoin today. So far all the people I've seen arguing against this change seem more interested in fueling conspiracy theories than actually explaining why it would be a bad move (and I get this vibe from your post as well).
So what's your position exactly? That the current issues with transfer fees and the long term usability of bitcoin are overstated? That they're real problems but it's too early for this push? That the solution is not the right one? But if not, which one?
* Realistically, can not be activated (95% support level required, way more than achievable). Means we'll stuck with current 1MB forever waiting for segwit
* Upon activation it does not add any benefits. Real increase in throughput will be achieved later, then all major players updated their client code, started crafting segwit transactions and moved coins to new segwit addresses. Means it delays throughput increase even more
* After full adoption, throughput will be increased from 1MB/10min up to ~1.7-2MB/10min while worst-case scenario (useless, specially crafted transactions) is 4MB - miners should be prepared for it. Means "2MB forever" and "hard to increase block size because miners should be prepared for 4x load"
There are other points as well, i'll stop here. Simple block size increase don't have such cons
This is not an argument against segwit, but against the method of it's activation. The rationale behind this high activation treshold is well summarized by greg maxwell [1]
> Upon activation it does not add any benefits. Real increase in throughput will be achieved later, then all major players updated their client code, started crafting segwit transactions and moved coins to new segwit addresses. Means it delays throughput increase even more
If only merchants or services who need to do lots transactions enable segwit, everyone benefits from the compressed output as there is more space on the chain for non-segwit wallets even if they don't upgrade or are aware of what segwit is
> After full adoption, throughput will be increased from 1MB/10min up to ~1.7-2MB/10min while worst-case scenario (useless, specially crafted transactions) is 4MB - miners should be prepared for it. Means "2MB forever" and "hard to increase block size because miners should be prepared for 4x load"
Miners should be prepared to give the service users want and pay for with fees. "Specially crafted transactions" included.
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017...
* It fixes transaction malleability and quadratic hashing problem. Transaction malleability is definitely a benefit upon activation. Oh... and it's also a block size increase so there is that benefit. Oh... and lightning network is basically ready. Oh... and rootstock. If the network NEEDS NEEDS NEEDS more capacity so badly, then throughput increases should happen very very quickly, because why would people wait to upgrade if the need is so incredibly dire.
* Don't even know what you're arguing here but "2MB forever" is not grounded in any sort of reality except one that people have made up.
Oh definitely not that - it's a huge problem! Places that accepted bitcoin no longer do, and bitcoin's market share is plummeting - there's no reason it every should have happened. But instead of a simple fix to the problem (upping a temporary limit put in place in 2010 - that's eight year old tech), now Blockstream is trying to push a massively complex revamping. It won't even help with the scaling problem - it only discounts Segwit enabled transactions (since Litecoin enabled Segwit, almost nothing has used it). It's primary purpose to enable second layer solutions Blockstream can consult on. Even if something like Segwit was a solution, FlexTrans is a much better way to go. Even if Segwit activated tomorrow, there'd be little-to-no backlog relieft, and Bitcoin would be forever saddled with inescapable tech debt.
to me it sounds like Segwit is trying to #1 fix a problem and #2 add new features.
Wouldn't it be a lot faster and less risky to first fix the problem (#1) and wait with implementing new features (#2) until all the problems are solved?
if (blocknumber > 500000) maxblocksize = 8000000;
A more longer term problem is the governance problems it entails. Large economic interest will want to adjust that value to their liking, so it should preferrably be a little more non-arbitrary.
So a more flexible approach is necessary, preferrably one that is backwards compatible for old nodes. Extension blocks, and a special form of extension blocks called segregated witness, can do exactly that. They have other problems, but most are pretty well understood by now, and most developers see segregated witness blocks as a way to more than double block size whilst minimizing risks.
(It also brought along the possibility to fix other long standing problems with the transaction format, so in the end several other things such as script versioning, uxto defragmentation and non-malleability was stuffed in there.)
I also see that some people worry that using bigger and bigger block sizes could end up "concentrating the mining power in the hands of a few miners" but since that already seems to be the case I'm not sure it's a very good counter argument.
It's pretty obvious to me that linearly scaling solutions like simply increasing the block size are not sufficient to achieve global mainstream adoption (at least without further centralizing mining), much less the sort of machine-to-machine / micropayment revolution that a scalable cryptocurrency could unlock.
Yes - the former now (or last year!) to resolve the massive backlog as new adopters come in. We later need something to enable greater scale than blocksize alone, but not yet; other cryptos like Ethererum are able to handle a much higher transaction throughput. When the time comes when something like SegWit IS needed, FlexTrans is a much better solution.
