Segwit violates practically every "best practice" of software engineering in existence. It makes wild changes to an emergent-behavior system (where it is absolutely key to make small changes at a time), it bundles unrelated changes, the adoption model is atrocious, it requires the entire ecosystem to start using a new transaction type to reap any benefit at all, it is premature optimization, it doesn't solve one bottleneck at a time, it ignores the actual bottleneck, and a future potential rollback puts all the money in such transactions in jeopardy.
I would not hire anybody who has worked on this.
Regardless, it is clear that it is not going to achieve a 95% hashpower majority, or even the new threshold of 80%, so it baffles me why it is still being discussed. It has no path to activation, and that was clear six months ago.
Thanks for the clarification! I also think it will not reach 95% (95% is very high in general). To be honest the only thing that must be addressed quickly is the malleability, it can be used to create long withdraw or no withdraw from exchanges (not sure why it hasn't been done yet). Bundling unrelated changes or many changes is indeed a bad practice. If anyone worked on high-end it-industry projects though, sometimes you have to what you have to do when the clock is ticking, but I don't see a clock ticking so there is no need to make rough stuff.
Sometimes you do have a clock ticking, but this problem has been known since at least 2011, and was being actively discussed in 2014.
"Malleability" is two unrelated problems, one of which has been fixed. It is (was) the ability to create the same transaction expressed differently -- transaction format malleability. Compare spending 4.00 USD vs. $4; this is written in two different but equally valid ways, and so a computer system can see it as different amounts.
This malleability has been fixed. There is now only one valid way to set a particular amount in a transaction. This affected exchanges.
The second malleability is a transaction ID malleability. Since the signature is based on a partial unknown at the time of signing, another signature can be made with another partial unknown, leading to a different transaction ID for the same transaction. This does not affect exchanges, but some future technologies that depend on a static transaction ID reference.
Thanks again, let me understand if I now get it right: say someone finds withdrawls transaction as soon as they are generated from the exchange, creates copy of them with different IDs and broadcast such messages. The network would assume all of them is correct and all of them represent the same transaction, some nodes will store that with an ID, some other with another ID, but from the point of view of the final wallet owner there is no difference in terms of waiting time.