Bitcoin developer Gregory Maxwell has written the following. on Reddit:
A design flaw exists in the Bitcoin protocol that allows a third-party to take your valid transaction and modify it so it is functionally identical, but has a different transaction number. It is difficult to write correct wallet software and can be used to invalidate a long chain of unconfirmed transaction chains that depend on a non-mutant transactions (since transactions are referred to by their txid).
This problem is due to a number of factors. One of these is OpenSSL’s willingness and ability to understand signatures with invalid encodes. A normal ECDSA signature encodes two large integers, the encoding isn’t constant length— if there are leading zeros you are supposed to drop them.
It is easy to write software that assumes signatures will always be the same length, and then add extra leading zeros.
This is a cautionary tale that is very important, as it is the reason we have chosen certain design decisions for our development philosophy. The issue is that many people keep bringing up the fact that we are unnecessarily creating the wheel in many places. own serialization format, RLPInstead of using existing protobuf We’re developing an application-specific scripting languages instead “just using Lua”. This is an important concern. commonly-used pejorative, so doing such in-house development does require justification.
The cautionary story I cited above is the perfect example for the justification I will give. The external technologies such as protobuf, Lua and OpenSSL are excellent and have many years of development, but they often were not designed with the perfect cryptographic integrity and consensus that cryptocurrency requires. OpenSSL is a perfect example. There are no other areas where you could take a valid hash and make it into another valid hash. But here, it is fatal. Ethereum has a core principle of simplicity. Its protocol should contain as few black boxes as possible and should be as easy to understand as possible. Each and every feature of each sub-protocol must be documented in the whitepaper, wiki or other official document. This specification should then be used to implement it. 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 – read the protobuf spec Compare it with the RLP spec Please read what I’m saying.
The above principle is not without its limitations. As an example, we would be foolish to think that we can invent everything. own The hash algorithm is the well-known and widely used SHA3, for signatures it’s the secp256k1 that Bitcoin uses, but instead of using OpenSSL buffer protocol, we use RLP for storing the v.r.s triple. (The v.r.s. is the extra two bits required for public key recovery) This is the kind of situation where “just using X” This is exactly the right way to go, as X has a clear and easily understandable interface. There are also no subtle differences among different implementations. There is no doubt that the SHA3 for an empty string in C++, Python and Javascript is c5d2460186…a470. Finding the right balance is what lies between these two extremes.
“This article is not financial advice.”
“Always do your own research before making any type of investment.”
Source: blog.ethereum.org
