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.
You are viewing a single comment's thread from:
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.