\n<\/p>\n
Bitcoin developer Gregory Maxwell writes the following on Reddit:<\/a><\/p>\n There is a design flaw in the Bitcoin protocol where its possible for a third party to take a valid transaction of yours and mutate it in a way which leaves it valid and functionally identical but with a different transaction ID. This greatly complicates writing correct wallet software, and it can be used abusively to invalidate long chains of unconfirmed transactions that depend on the non-mutant transaction (since transactions refer to each other by txid).<\/p>\n This issue arises from several sources, one of them being OpenSSL\u2019s willingness to accept and make sense of signatures with invalid encodings. A normal ECDSA signature encodes two large integers, the encoding isn\u2019t constant length\u2014 if there are leading zeros you are supposed to drop them.<\/p>\n It\u2019s easy to write software that assumes the signature will be a constant length and then leave extra leading zeros in them.<\/p>\n This is a very interesting cautionary tale, and is particularly important because situations like these are part of the reason why we have made certain design decisions in our development philosophy. Specifically, the issue is this: many people continue to bring up the point that we are in many places unnecessarily reinventing the wheel, creating our own serialization format, RLP<\/a>, instead of using the existing protobuf<\/a> and we\u2019re building an application-specific scripting language instead of \u201cjust using Lua\u201d. This is a very valid concern; not-invented-here syndrome is a commonly-used pejorative<\/a>, so doing such in-house development does require justification.<\/p>\n And the cautionary tale I quoted above provides precisely the perfect example of the justification that I will provide. External technologies, whether protobuf, Lua or OpenSSL, are very good, and have years of development behind them, but in many cases they were never designed with the perfect consensus, determinism and cryptographic integrity in mind that cryptocurrencies require. The OpenSSL situation above is the perfect example; aside from cryptocurrencies, there really is no other situations where the fact that you can take a valid signature and turn it into another valid signature with a different hash is a significant problem, and yet here it\u2019s fatal. One of our core principles in Ethereum is simplicity; the protocol should be as simple as possible, and the protocol should not contain any black boxes. Every single feature of every single sub-protocol should be precisely 100% documented on the whitepaper or wiki, and implemented using that as a specification (ie. test-driven development). Doing this for an existing software package is arguably almost as hard as building an entirely new package from scratch; in fact, it may even be harder, since existing software packages often have more complexity than they need to in order to be feature-complete, whereas our alternatives do not \u2013 read the protobuf spec<\/a> and compare it to the RLP spec<\/a> to understand what I mean.<\/p>\n Note that the above principle has its limits. For example, we are certainly not foolish enough to start inventing our own hash algorithms, instead using the universally acclaimed and well-vetted SHA3, and for signatures we\u2019re using the same old secp256k1 as Bitcoin, although we\u2019re using RLP to store the v,r,s triple (the v is an extra two bits for public key recovery purposes) instead of the OpenSSL buffer protocol. These kinds of situations are the ones where \u201cjust using X\u201d is precisely the right thing to do, because X has a clean and well-understood interface and there are no subtle differences between different implementations. The SHA3 of the empty string is c5d2460186…a470 in C++, in Python, and in Javascript; there\u2019s no debate about it. In between these two extremes, it\u2019s basically a matter of finding the right balance.<\/p>\n<\/div>\n