Monday, November 24, 2025
HomeEthereumWhy Not Simply Use X? An Instructive Instance from Bitcoin

Why Not Simply Use X? An Instructive Instance from Bitcoin


Bitcoin developer Gregory Maxwell writes the next on Reddit:

There’s a design flaw within the Bitcoin protocol the place its doable for a 3rd celebration to take a sound transaction of yours and mutate it in a means which leaves it legitimate and functionally equivalent however with a unique transaction ID. This drastically complicates writing appropriate pockets software program, and it may be used abusively to invalidate lengthy chains of unconfirmed transactions that rely on the non-mutant transaction (since transactions refer to one another by txid).

This concern arises from a number of sources, certainly one of them being OpenSSL’s willingness to just accept and make sense of signatures with invalid encodings. A traditional ECDSA signature encodes two giant integers, the encoding isn’t fixed size— if there are main zeros you might be purported to drop them.

It’s straightforward to write down software program that assumes the signature shall be a continuing size after which depart additional main zeros in them.

This can be a very attention-grabbing cautionary story, and is especially necessary as a result of conditions like these are a part of the explanation why we have now made sure design selections in our growth philosophy. Particularly, the difficulty is that this: many individuals proceed to convey up the purpose that we’re in lots of locations unnecessarily reinventing the wheel, creating our personal serialization format, RLP, as an alternative of utilizing the present protobuf and we’re constructing an application-specific scripting language as an alternative of “simply utilizing Lua”. This can be a very legitimate concern; not-invented-here syndrome is a commonly-used pejorative, so doing such in-house growth does require justification.

And the cautionary story I quoted above supplies exactly the proper instance of the justification that I’ll present. Exterior applied sciences, whether or not protobuf, Lua or OpenSSL, are excellent, and have years of growth behind them, however in lots of instances they had been by no means designed with the proper consensus, determinism and cryptographic integrity in thoughts that cryptocurrencies require. The OpenSSL state of affairs above is the proper instance; except for cryptocurrencies, there actually isn’t any different conditions the place the truth that you’ll be able to take a sound signature and switch it into one other legitimate signature with a unique hash is a major downside, and but right here it’s deadly. One among our core rules in Ethereum is simplicity; the protocol needs to be so simple as doable, and the protocol shouldn’t comprise any black bins. Each single characteristic of each single sub-protocol needs to be exactly 100% documented on the whitepaper or wiki, and applied utilizing that as a specification (ie. test-driven growth). Doing this for an present software program bundle is arguably nearly as arduous as constructing a wholly new bundle from scratch; actually, it could even be tougher, since present software program packages typically have extra complexity than they should as a way to be feature-complete, whereas our alternate options don’t – learn the protobuf spec and examine it to the RLP spec to know what I imply.

Word that the above precept has its limits. For instance, we’re definitely not silly sufficient to start out inventing our personal hash algorithms, as an alternative utilizing the universally acclaimed and well-vetted SHA3, and for signatures we’re utilizing the identical outdated secp256k1 as Bitcoin, though we’re utilizing RLP to retailer the v,r,s triple (the v is an additional two bits for public key restoration functions) as an alternative of the OpenSSL buffer protocol. These sorts of conditions are those the place “simply utilizing X” is exactly the suitable factor to do, as a result of X has a clear and well-understood interface and there aren’t any refined variations between completely different implementations. The SHA3 of the empty string is c5d2460186…a470 in C++, in Python, and in Javascript; there’s no debate about it. In between these two extremes, it’s mainly a matter of discovering the suitable stability.

RELATED ARTICLES

Most Popular

Recent Comments