[simias]

I'm an external observer in all of this and I was reading some discussion about this earlier, could you explain your position to those like me who aren't very familiar with this issue?

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?

[out_of_protocol]

Why segwit is not good:

* 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

[phaser]

> Realistically, can not be activated (95% support level required, way more than achievable). Means we'll stuck with current 1MB forever waiting for segwit

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...

[Zarath]

* It can be activated through UASF or through BIP149 which supposedly (big supposedly here) has been agreed to by a majority of miners

* 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.

[JustinAiken]

> So what's your position exactly? That the current issues with transfer fees and the long term usability of bitcoin are overstated?

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.

[DavideNL]

I'm an external observer also (with little knowledge about the BTC internals);

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?

[r1ch]

Segwit is an complicated and large code change that fundamentally alters the bitcoin protocol to solve a problem that can instead be fixed by adding:

if (blocknumber > 500000) maxblocksize = 8000000;

[xorcist]

That suggestion has been put forward a number of times since the limit was put in place. One problem with that is that it is a backwards incompatible change so there need to be some signalling mechanism in place to ensure the rule change takes place at the same block height for every node. The logic would need to have been put in years before it activates.

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.)

[6nf]

> The logic would need to have been put in years before it activates.

But we HAD years to do this. Why didn't we do it?

[xorcist]

Well, "we" did. It just took longer than most people thought. Segwit was put in last year, it just hasn't activated yet.

Why did it take so long to develop? I think it's a combination. Many people wanted to get it right, a bad solution could be worse than no solution. There was also concern about miners blocking it, as many had been very skeptical about lowered fees.

Why does it take so long to active? Yeah, this is the tough one. It was deployed the same way as other soft forks. But this turned out to be quite contentious as it played right into an ongoing governance conflict. Worst case, the current deployment has to time out later this year and then it can be safely re-done.

[simias]

But isn't that just a temporary workaround? And it doesn't address the other issues SegWit tries to solve, like allowing "instantaneous" transactions? How can Bitcoin ever hope to become a mainstream currency if you have to way dozens of minutes for your transaction to be validated?

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.

[r1ch]

Make it unlimited then, or grow dynamically based on historical block sizes, there's lots of options. The original limit was only added as an anti-spam measure back when anyone could mine blocks.

I would rather the core developers focus on the current capacity problems and deal with use cases like instant transactions at another time. Make bitcoin work as it's supposed to and let the community decide on adding features later - don't try to push them both together.

[xorcist]

An unbounded block size would bring about a number of attacks. Denial of service attacks would be trivial. There's a reason Satoshi put a limit there in the first place.

[simias]

That's fair. I thank you and out_of_protocol, it was a lot more more informative than all of my bitcoin forum reading earlier...

[out_of_protocol]

I don't see how segwit helps here (how it does "instantaneous" stuff?), more like other way around: by ensuring small block side it grants perma-queue and therefore confirmation delays

[xorcist]

Segwit as it is currently implemented removes the fixed block size, and replaces it with a variable block size which is 2-4x larger than current blocks. So it is very much the opposite of what you describe.

[Zarath]

Bitcoin cannot survive without a permanent transaction backlog once the block reward subsidy is gone. Either we move to having inflation or there is a backlog.

[Zarath]

A blocksize increase doesn't fix transaction malleability or quadratic hashing or fix covert asicboost or enable use of lightning network. Also IIRC greg maxwell has said the actual segwit code is like 2-3000 lines whereas the rest is testing.