can someone point me to hard (objective) technical evidence AGAINST SegWit?

[rico666]

Thanks for the
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179
it is very thorough in describing SW.

In fact so thorough, that for the "Problems with SW" only about 30% of the article remain.
Naturally I had a deeper look at these

as for 3.1 SW creates a financial incentive for bloating witness data

... there exists a financial incentive for malicious actors to design transactions with a small base size but large and complex witness data.

Unfortunately it's not elaborated what this financial incentive is or how it comes into play. Maybe I'm overlooking something evident, but as is in the article it is a simple statement without any proof or even explanation.

as for 3.2 SW fails to sufficiently address the problems it intends to solve

This section contains a very weak, almost no-argument against SW, namely

Linear signature hashing and malleability fixes will only be available to the SW UTXO.

i.e. "The good properties of SW will not be available to non-SW UXTOs", which in itself is a homage to SW and similar to the argument like

"But Bitcoin will not fix the USD..."

On the other hand, it contains a very strong argument - the strongest I've seen so far - against a new UXTO class:

influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”

I followed the link to the reddit discussion and I didn't believe what I've read. If there are really people in the Bitcoin community who want to put an expiration date to Bitcoins, and some UXTO discrimination should help these f*cktards to achieve their wet fantasies. Then I have to agree: We cannot have that.

It doesn't seem like a genuine SW-UXTO problem though, more than SW-UXTO being a vehicle for discrimination according to hypothetical future bad politics. This seems like killing your newborn, because it might become Hitler.

=> Again, no technical argument, merely a political. But it surely scared the shit out of me.


as for 3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits

It essentially says: "There is code change involved and that's dangerous, SW does not provide enough benefit to justify the risk of bugs in the new code."

Well - the question is, if BU or other proposals do provide enough benefit, because as is, this argument could be interpreted as "Never change a running system".

as for 3.4 Economic distortions and price fixing

purely non-technical and may be titled "I do not like soft-forks"

as for 3.5 Soft fork risks

reiteration of "I do not like soft-forks"

as for 3.6 Once activated, SW cannot be undone and must remain in Bitcoin codebase forever.

While not providing evidence for the claim there could be no roll-back, I give him that: Not having a plan B (roll-back) for the case of some catastrophic sideways fuggup is a bad thing. In general.


Executive Summary:

SW may give zealots the possibility to discriminate between SW-UXTOs and non-SW-UXTOs (a.k.a. our old good UXTOs) and as such might help foster some "interesting" novel Bitcoin policies, like destroying old coins etc.

Well - theoretically - it might. But I believe this is also a non-technical issue and more an educational one. Should such an issue arise, the bitcoin community should still be "man enough" to take a stick and beat the shit out of such zealots until they come to reason.

Executive executive Summary:

SW is like a knife: It can be useful in the kitchen, or you might slash your wrist with it. Should we ban knives?


Rico

[1715085844]

1715085844

[1715085844]

1715085844

[jonald_fyookball]

Rico, good post.  i may look into some of this stuff.

almost feels like Nancy Pelosi saying "we need to pass obamacare so we can find out whats in the bill"

this thing is huge and messy.

and people think its a good idea to activate this BEFORE we simply increase the blocksize?  why??

[classicsucks]

Thanks for the
https://medium.com/the-publius-letters/segregated-witness-a-fork-too-far-87d6e57a4179

On the other hand, it contains a very strong argument - the strongest I've seen so far - against a new UXTO class:

influential individuals associated with Bitcoin Core: Greg Maxwell has postulated that “abandoned UTXO should be forgotten and become unspendable,” and Theymos has claimed “the very-rough consensus is that old coins should be destroyed before they are stolen to prevent disastrous monetary inflation.”

I followed the link to the reddit discussion and I didn't believe what I've read. If there are really people in the Bitcoin community who want to put an expiration date to Bitcoins, and some UXTO discrimination should help these f*cktards to achieve their wet fantasies. Then I have to agree: We cannot have that.

It doesn't seem like a genuine SW-UXTO problem though, more than SW-UXTO being a vehicle for discrimination according to hypothetical future bad politics. This seems like killing your newborn, because it might become Hitler.

=> Again, no technical argument, merely a political. But it surely scared the shit out of me.

That section also stood out to me, because I wasn't aware of this issue, I know that UTXO bloat is a big concern for everybody.  

I suppose the Core devs mean that, assuming Segwit activation plus some percentage, the old UTXO set SHOULD be near empty and could be retired?

To me this shows Core's level of arrogance in assuming that everyone would be running their code...
 

as for 3.3 SW places complex requirements on developers to comply while failing to guarantee any benefits

It essentially says: "There is code change involved and that's dangerous, SW does not provide enough benefit to justify the risk of bugs in the new code."

Well - the question is, if BU or other proposals do provide enough benefit, because as is, this argument could be interpreted as "Never change a running system".

Segwit changed 5,000 lines of code in bitcoin core, and requires refactoring thousands of lines of code in exchange, wallet, and utility software. Statistically guaranteeing 100+ bugs.

Executive executive Summary:

SW is like a knife: It can be useful in the kitchen, or you might slash your wrist with it. Should we ban knives?

No one is banning knives.

This oddly-shaped Segwit knife that requires everyone to build new knife racks is being put back in its packaging and returned to the vendor. We've still got a ton of cutting to do, and there is a Unlimited knife handy that claims to enable us to do that cutting. Many are using it simply because it's an alternative.

It sure would be nice to just have a knife that works and everyone can use.

[jonald_fyookball]

There must be a typo there...For a second it looked like you said 50,000 lines of code.

[classicsucks]

There must be a typo there...For a second it looked like you said 50,000 lines of code.

Sorry it's 5.305 lines added, 571 lines removed, for a total of 5,876 changed lines, in EIGHTY files. https://github.com/bitcoin/bitcoin/pull/8149/files

Industry average being 15-50 defects per thousand lines of code (source: Code Complete), would yield  87 - 290 bugs in Segwit. Most would be minor, but a few... Not to mention the implementation bugs in 3rd party wallet, exchange, and utility code. A nightmare. Or, maybe job security for a bunch of coders?

[Carlton Banks]

There must be a typo there...For a second it looked like you said 50,000 lines of code.

Sorry it's 5.305 lines added, 571 lines removed, for a total of 5,876 changed lines, in EIGHTY files. https://github.com/bitcoin/bitcoin/pull/8149/files

Industry average being 15-50 defects per thousand lines of code (source: Code Complete), would yield  87 - 290 bugs in Segwit. Most would be minor, but a few... Not to mention the implementation bugs in 3rd party wallet, exchange, and utility code. A nightmare. Or, maybe job security for a bunch of coders?

You forgot to subtract all the LoC that are adapted or new testing code They form most of the changes, i.e. the Bitcoin devs are being as assiduously diligent as possible.

You also forgot to mention how many bugs have been found and fixed (having not caused any incident, as you'd be shouting about it from the roof of your tower block) on the Bitcoin Testnet, which has been running live Segwit for over 6 months

[K128kevin2]

Segwit changed 5,000 lines of code [...] Statistically guaranteeing 100+ bugs.

That's... not how it works. I think that the core developers have been quite responsible, a lot of unit tests have been written for the code changes.

[franky1]

You also forgot to mention how many bugs have been found and fixed (having not caused any incident, as you'd be shouting about it from the roof of your tower block) on the Bitcoin Testnet, which has been running live Segwit for over 6 months

litecoin has been running for 6 years..
but i dare you to start throwing litecoin rules and keys into bitcoin on activation day.

there is a big bug known about since last year. instead of fixing it, they are doing work arounds.
such as the upstream downstream. not relaying segwit unconfirmed tx's to native nodes, banning native nodes from being upstream and preventing native blocks from being produced ontop of segwit...

yet you will remain adamant thats is all "compatible" LOL

[classicsucks]

Segwit changed 5,000 lines of code [...] Statistically guaranteeing 100+ bugs.

That's... not how it works. I think that the core developers have been quite responsible, a lot of unit tests have been written for the code changes.

I didn't say the devs weren't responsible. 15-50 defects per KLOC is a software industry average. Add in one defect per thousand lines for each covert NSA/CIA employee at the company. /s

Test code can have bugs in it, and when it does, they can obscure bugs in the main code.

Unit tests often miss higher-level bugs that require live interaction, timing, or edge case scenarios. Like, say protocol changes on a live running network with thousands of contentious and/or malicious actors?

Bugs in Segwit have been found and fixed. But you can never really certify code bug-free. That's why it's best to keep changes as simple as possible and keep the total lines changed to a minimum.  

Nobody shouting from any towers here, Carlton. Unless you are?

All software has bugs. The questions are: has anyone found them, what are their consequences, and how easily can they be fixed?

Sometimes the bug is in the dev's head - there seems to be an innate desire of the coder to over-complicate matters... known colloquially as "Error occurred between keyboard and seat".

[Jet Cash]

Surely SegWit provides a lot more advantages than just a solution to the problems of transaction delays. SegWit increases the potential intelligence that can be built into transactions.

I understand the problems, but I still believe that it would be better to try to find ways to decrease the block generation time to keep Bitcoin fast and agile, rather than increasing the blocksize so that it is about as fast as a McDonalds customer.

[AngryDwarf]

Segwit changed 5,000 lines of code [...] Statistically guaranteeing 100+ bugs.

That's... not how it works. I think that the core developers have been quite responsible, a lot of unit tests have been written for the code changes.

I didn't say the devs weren't responsible. 15-50 defects per KLOC is a software industry average. Add in one defect per thousand lines for each covert NSA/CIA employee at the company. /s

Test code can have bugs in it, and when it does, they can obscure bugs in the main code.

Unit tests often miss higher-level bugs that require live interaction, timing, or edge case scenarios. Like, say protocol changes on a live running network with thousands of contentious and/or malicious actors?

Bugs in Segwit have been found and fixed. But you can never really certify code bug-free. That's why it's best to keep changes as simple as possible and keep the total lines changed to a minimum.  

Nobody shouting from any towers here, Carlton. Unless you are?

All software has bugs. The questions are: has anyone found them, what are their consequences, and how easily can they be fixed?

Sometimes the bug is in the dev's head - there seems to be an innate desire of the coder to over-complicate matters... known colloquially as "Error occurred between keyboard and seat".

In my experience, asynchronous issues that can occur on a live system are very difficult to replicate in a test environment. They can be very difficult to diagnose and fix.

[classicsucks]

Unit tests often miss higher-level bugs that require live interaction, timing, or edge case scenarios. Like, say protocol changes on a live running network with thousands of contentious and/or malicious actors?

Bugs in Segwit have been found and fixed. But you can never really certify code bug-free. That's why it's best to keep changes as simple as possible and keep the total lines changed to a minimum.  

In my experience, asynchronous issues that can occur on a live system are very difficult to replicate in a test environment. They can be very difficult to diagnose and fix.

The Segwit soft fork has the potential for a TON of these types of issues. As you say, they're very time-consuming to find and fix. At this point it's likely that Segwit will not move forward, and development will probably need to shift in some way. If Core tries to ram Segwit through with a UASF (User activated soft fork), the Bitcoin Unlimited folks will likely try to hard fork the blockchain. In this case there could be as many as 5 different bitcoin implementations fighting for the highest adoption for consensus. A crazy scenario, likely to be very contentious. If this does come to pass, it will forever be part of software development history! And you'd better believe that there will be some hard lessons on why you must test your code extensively and keep it simple...

[ebliever]

In my experience, asynchronous issues that can occur on a live system are very difficult to replicate in a test environment. They can be very difficult to diagnose and fix.

But what is the alternative, to sit and do nothing beyond hoping endless blocksize increases can cope somehow with user adoption rates? I suppose an altcoin can be cajoled into doing SW first, but that should have been done a year ago if really needed.

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

Core and Bitcoin Unlimited now exemplify the dichotomy in how Bitcoin approaches these two risks. On the one hand we have the "Go-too-slow" approach of Core, which has been patiently waiting for miners to adopt SW/LN while the rest of the crypto space keeps advancing. On the other hand we have the buggy development of hard-charging Bitcoin Unlimited and their "You have to fork it to find out what's in it" approach handing over protocol power to the miners in an unprecedented and risky manner.

[dinofelis]

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

You got it.  So a coin should remain itself, and when it is outdated, people should switch to other coins.  Simple as that.  The coin remaining itself can maybe still maintain a niche application.  And most probably what will happen in the long run.

[krile]

I am also looking for evidence against SegWit but am having problems finding something substantial. Most of it is political, not technical...

What is the status of the "lets do nothing camp"?

On https://coin.dance/blocks#hashrate I noticed a few pools signal neither (SegWit/BU):

https://pool.btc.com/
https://bixin.com/
http://solo.ckpool.org/
http://btc.top/
https://xbtc.exx.com/

to name a few.

Do they even know all this debate is going on?

[classicsucks]

I am also looking for evidence against SegWit but am having problems finding something substantial. Most of it is political, not technical...

I guess you didn't even read this thread or the links posted in it? I count the word "code" 36 times on this page alone. If the thread still isnt technical enough for you after you're actually read it (and the articles linked), read the code. It's an attempt to rewrite the signature layer of bitcoin, and these changes are supposed to propagate on the live network without breaking anything.

Also, you implyiing that technical arguments are more "substantial" than political ones?

[classicsucks]

But what is the alternative, to sit and do nothing beyond hoping endless blocksize increases can cope somehow with user adoption rates? I suppose an altcoin can be cajoled into doing SW first, but that should have been done a year ago if really needed.

They already tried to ram Segwit down Litecoin users' throats:

https://www.litecoinpool.org/pools
How much of the hashing power is signaling SegWit support? NEW!
    About 540 GH/s, or 22.0% of the network (110 out of the last 500 blocks).

Total fail. No one wants this!

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

I agree with this assessment. However, bitcoin has always had flaws other than the artificially constrained blocksize and the resultant high fees and slow confirmations. Difficulty re-targeting is broken. The currency emission rate is not optimal, etc.. But Bitcoin has the largest market cap and a huge lead in adoption, credibility, and investment.   That said, its first mover advantage is fading as we speak.

Core and Bitcoin Unlimited now exemplify the dichotomy in how Bitcoin approaches these two risks. On the one hand we have the "Go-too-slow" approach of Core, which has been patiently waiting for miners to adopt SW/LN while the rest of the crypto space keeps advancing. On the other hand we have the buggy development of hard-charging Bitcoin Unlimited and their "You have to fork it to find out what's in it" approach handing over protocol power to the miners in an unprecedented and risky manner.

You present a false dichotomy - firstly they are not opposites, secondly they are not the only options on the table. Segwit is a wonky code fork that will be forgotten in 2 years. BU is a wacky attempt to challenge Core's status quo, and will also likely be forgotten in two years. Hard fork to 2MB blocks with no other changes from 0.12 is still possible at any time. A bitcoin hard fork was done in 2014 without issue.

[dinofelis]

But what is the alternative, to sit and do nothing beyond hoping endless blocksize increases can cope somehow with user adoption rates? I suppose an altcoin can be cajoled into doing SW first, but that should have been done a year ago if really needed.

They already tried to ram Segwit down Litecoin users' throats:

https://www.litecoinpool.org/pools
How much of the hashing power is signaling SegWit support? NEW!
    About 540 GH/s, or 22.0% of the network (110 out of the last 500 blocks).

Total fail. No one wants this!

The dilemma Bitcoin is now in runs as follows: Cryptocurrency is rapidly innovating, and coins that lack the feature set and capabilities of newer coins are likely to die out no matter how popular they once were. (That's why we no longer see Model T's on the road.) On the flip side, technical issues or exploits associated with changes can kill a coin real fast.

I agree with this assessment. However, bitcoin has always had flaws other than the artificially constrained blocksize and the resultant high fees and slow confirmations. Difficulty re-targeting is broken. The currency emission rate is not optimal, etc.. But Bitcoin has the largest market cap and a huge lead in adoption, credibility, and investment.   That said, its first mover advantage is fading as we speak.

Core and Bitcoin Unlimited now exemplify the dichotomy in how Bitcoin approaches these two risks. On the one hand we have the "Go-too-slow" approach of Core, which has been patiently waiting for miners to adopt SW/LN while the rest of the crypto space keeps advancing. On the other hand we have the buggy development of hard-charging Bitcoin Unlimited and their "You have to fork it to find out what's in it" approach handing over protocol power to the miners in an unprecedented and risky manner.

You present a false dichotomy - firstly they are not opposites, secondly they are not the only options on the table. Segwit is a wonky code fork that will be forgotten in 2 years. BU is a wacky attempt to challenge Core's status quo, and will also likely be forgotten in two years. Hard fork to 2MB blocks with no other changes from 0.12 is still possible at any time. A bitcoin hard fork was done in 2014 without issue.

Wise words.  Agree with everything in this post.
(apart from the hard fork in 2014 ?  Hard fork in the block chain protocol ??)

[Xester]

I could find none. Only political whimsical yadda yadda.
In order to exclude a cognitive BIAS, I hereby ask to be pointed to $SUBJECT.



Rico

Segwit is good and I can say that it is much better than HF since HF is a danger to bitcoin. But even if segwit is safe there will be problems that will come later on. But let us just watch how segwit will perform since it is already  clear that segwit will use Lightning Network. As of this time it is hard to say if there are serious advantages.

[classicsucks]

(apart from the hard fork in 2014 ?  Hard fork in the block chain protocol ??)

Yes there was an emergency hard fork in March 2013 (not 2014, I stand corrected). 60% of mining hashpower was building on a broken blockchain due to an incompatibility introduced by the switch to LevelDB. The blockchain was rolled back and nodes quickly downgraded to the previous 0.7 version.
 
https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

New code with new rules for validation were rolled out on an emergency basis. Network and pool operators worked together and the issue was resolved in 3 days.


Of course devs don't like to admit that hard forking can work just fine, even on an emergency basis with no warning. They will tell you that "the network is too big now", "there are malicious actors", "you can't get consensus with this many people now", etc. And yet they claim that soft forking is "completely safe"...

Some have argued that every time a block gets orphaned there is a hard fork. Semantics.