With Bitcoin’s enormous success, the term “cryptocurrency” has passed into the vernacular, so much so that the word is now even enshrined in the *OED*.

A quick preliminary bit of disambiguation: Bitcoin is a cryptocurrency; not all cryptocurrencies are Bitcoin. Ether is a cryptocurrency, Litecoin is a cryptocurrency, XPR is…another story. None of them are Bitcoin.

The question I wish to attack here is not a definition of the word *cryptocurrency*, but, rather, a look at one aspect of its etymology. Why *crypto-* ? The prefix is well enough known, and stems from the Greek *kryptos*, which means “hidden”. Ah, but not hidden in the way you might first expect it to be. Mistake to avoid: thinking that cryptocurrencies are crypto- because their users are pseudonymous.

The crypto- in cryptocurrency stems from another form of crypto: cryptography, the branch of mathematics in which electronic cash pioneer David Chaum excelled. In my post about Chaum, I touched somewhat cursorily on the philosophical movements – Crypto-Anarchy and Cypherpunk – that furthered Chaum’s ideas and developed an ideology whereby privacy was to be protected through the use of cryptography.

Cryptocurrencies are the application of cryptography (and crypto-anarchist thought) to the field of money. Thus it’s the crypto- in *cryptography* that accounts for the crypto- in cryptocurrency. While, on the surface, cryptocurrencies are decentralized and pseudonymous, they are powered under the hood by a pair of cryptographic engines: a cryptographic hashing function and a digital signature algorithm.

In the case of Bitcoin, the hashing function is known as SHA-256 (SHA just means Standard Hashing Algorithm) and the signature algorithm is ECDSA, the Elliptic Curve Digital Signature Algorithm.

What follows is an explanation of both of these for people who don’t speak Advanced Math. No equations were harmed in the writing of this post.

**Hashing Functions and SHA-256**

A cryptographic hashing function does one relatively simple thing:* it turns an input of any length into an output of fixed length*. One such function (and the one used by Bitcoin) is SHA-256. Feed something digital (your name, the Manhattan phone book, a picture of your new puppy, the last two seasons of *Game of Thrones*, etc.) into SHA-256, and out will come a series of 256 1s and 0s. (Whence the 256 in the function’s name.)

For convenience’s sake, the resulting output (the *hash*) is generally notated hexadecimally. That means in base 16. That means it’s going to be a jumble of 32 digits between 0 and 9, and the letters *a* through *f*.

There are a number of hash calculators on the Internet. One such can be found at https://www.xorbin.com/tools/sha256-hash-calculator. I recommend you click on the link and try it out.

If you hash my name, you obtain:

735a4ab9b1117665394485bc12dd005c5ffc369ee64a5b58cbeca6fea5d900ca

And if you hash my recent Birgit Nilsson post, you obtain:

e5a10609011c835057d653e1c93b06076f4a480b88a46c9736ccb0458d69e1c0

Both comprise 32 hexadecimal “digits” (convertible to 256 1s and 0s), although the Nilsson post is a lot longer than my name.

(And, should you want the Nilsson hash in its original form of 256 1s and 0s, you get:

1110010110100001000001100000100100000001000111001000001101010000010101111101011001010011111000011100100100111011000001100000011101101111010010100100100000001011100010001010010001101100100101110011011011001100101100000100010110001101011010011110000111000000.)

You can hash pretty much anything. You also needn’t worry about running out of possible hashes. Exponential numbers grow, well, exponentially, and there are 2^{256} possible combinations of 1s and 0s that are 256 digits long. That’s in the neighborhood of 10^{77}, or one hundred quatturovigintillion. Estimates place the number of atoms in the known universe at around 10^{78} (a quinvigintillion.)

There are therefore plenty of SHA-256 hashes to go around, which is a good thing in light of the first of the two properties all hashing functions share:

- two separate inputs cannot have the same hash, and
- one shouldn’t be able to reverse the hashing process and get the input from the output.

If either of these conditions is not met, the hashing function is useless and gets thrown onto the same mathematical trash heap as the theorem about all Fermat numbers being prime.

In something of a nutshell, hashing functions create non-reversible codes for a given input. But what use would such a non-reversible code have?

They’re surprisingly practical. Just ask Satoshi Nakamoto. They even have their everyday uses: if you have two files (let’s say vacation pictures) and you’re not sure whether they’re identical or not, hash them. If they produce the same hash, they’re identical. If not, they’re different. Remember that: it will come in handy someday.

**Elliptic Curve Digital Signature Algorithm**

We know that Bitcoin is pseudonymous. If I wish to transfer some of my bitcoin to you, however, I’m effectively writing a check. And checks require signatures, which means me signing my own name. That creates the following problem: how can transactions be “signed” pseudonymously?

Enter the digital signature.

We all have some experience with the concept: the PIN you enter when making a purchase with a debit card is a primitive digital signature. You type in your magic number and the money is deducted from your account. There are, however, only 10,000 possible four-digit PINs . You don’t need much of a computer to foil that.

Bitcoin transactions require greater security – and that level of pseudonymity. Your debit card, PIN and checking account can be traced back to you in a split second.

The idea of a cryptographic signature protocol through which a transaction can be verified without revealing the identities of the two people making the transaction goes back to David Chaum. Fast forward a few decades and one of the results is ECDSA, the Elliptic Curve Digital Signature Algorithm.

As the name attests, the Elliptic Curve Digital Signature Algorithm uses Elliptic curves. An elliptic curve looks something like this:

The ECDSA uses certain pre-selected elliptic curves to set up a system of what are called *private* and *public keys*. If you take out all the math (and there is a lot of it) you get this: the person with the bitcoin has a really big secret number that allows the release of the funds. The person receiving the funds gets a smaller great big number to prove that he’s entitled to receive the funds. The curves come in because they determine the relationship between the private and public keys.

The sender’s big number is the private key. The recipient’s big number is called a public key. When making a transaction, the sender communicates the public key to the recipient while retaining the private key for himself. Keeping the private key safe means that no one will be able to forge a bitcoin check.

There’s more to be said about both hashing functions and digital signature algorithms, although the usefulness of the latter to a cryptocurrency is pretty evident: transactions need signatures. Just why they need hashing functions is something to be discussed at a later time.

[…] I wrote my introduction to hashing functions and digital signatures, I failed to mention that both SHA-256 and ECDSA, like many cryptographic tools, is the product of […]

LikeLike