Why Cryptocurrency is Crap – Part 1

From the Splainer-man not Man-splainin Dept.

If you want me to close the browser tab on something, all you have to do is mention cryptocurrency or blockchain unironically. I recently learned about DAOs and my eyes rolled so hard, right out of their sockets.

And you thought Nigerian prince scams were sad

I get asked about crypto and NFTs and the bitcoins all the time, but to explain in layman’s terms because none of my friends or family members are Computer Science/Engineering graduates. Every article that attempts to explain the topic will sortof talk about the blockchain, and maybe mention “proof of work” or “proof of stake”, “consensus mechanisms” but they don’t actually explain what those things are, what they actually mean. They just kindof wave their hands like “don’t worry about it” or “MAGIC” . And recently my son asked me to explain exactly what it is, so... here you go.

If you know of someone you love who has any significant part of their savings or retirement portfolio invested in anything to do with ANY cryptocurrency, perhaps you might want to slide this over to them to read.

TL;DR:

Cryptocurrency is dangerous crap for all the reasons it's proponents say it is the next thing since sliced bread. To explain to you why cryptocurrency is dangerous bullshit, I need to show you where it comes from – seemingly thin air. To show you that it magically coalesces out of thin air, I need to explain how it is produced, and that will take a little time. Then, we need to talk about financial economics and money theory for a bit. Then you'll throw your tapioca against the wall and fire up your fidelity.com account to make sure you're nowhere near anything crypto-related.

Blockchain Hocus Pocus would be a great band name

Suppose we have a series of transactions that we want to keep track of. Let’s call this the ledger. In the ledger of a bunch of financial transactions, – for example – if you want to make a transaction, it has to be done with the blessing of a central authority: the bank itself (or its computers). The problems with this type of ledger are:

Networked computers were supposed to help us get around problems like this. Back in the late 90s and early 2000s, the problem of not being able to download digital music, video, and files from central authorities was literally that those (websites/services) didn't exist yet. Or if they did, they were charging outrageous prices or crippling downloads with so much DRM it made the media unusable. So people created peer-to-peer file sharing systems like Napster and Limewire, and later on, BitTorrent software. P2P file distribution got around all 3 of our problems.

So what if we could have a whole network of participating computers manage, using peer-2-peer transfers, an open distributed ledger of data instead? A ledger of file transactions. A history of change edits, medical records, you name it.

Ok. So now we have a bunch of computers – nodes – all participating in our open ledger. If a node wants to make a transaction or add an event or a record to the ledger, it announces it to its peers, and the transaction/event/record slowly gets spread around the whole network. Depending on various internet-y things, it could take a while for announcements of transactions to get around. The order of transactions in YOUR local copy of the ledger might be different from the order in someone else’s. And how do we add new transactions to our ledger in a way that the record becomes indelible? How do we get everyone in the network to agree on the same version of history? How do we make it so noone can tamper with it?

Hashes are only good in data transfer and breakfast.

So we’ve collected together a bunch of pending, invalidated transactions from our peers. One way computers can make sure that transmitted or archived data doesn’t change over time is to calculate a checksum or a “hash” for a chunk of data. File transfers do this all the time. Before browsers and mobile clients started doing this automatically behind the scenes, and especially back when large files could be zipped or chunked into smaller bits, and you wanted to make sure each part was downloaded to transmitted properly, you could also download a checksum or hash file to go with each. You’d run a verification tool on your downloaded data, and if the hash it produced matched the checksum file, you knew your data was good. If not, you’d go download it again.

Note that a hash isn’t encryption. A hash is simply a characteristic fingerprint. The same hash algorithm run on the same data will always produce the same hash value. Always.

So, for any data, we can compute a hash; there are many types, but a common one is an MD5 hash, which represents a chunk of bytes as a 128-bit value. If I calculate an MD5 hash on the previous paragraph, I get the following:

e73435e3a4af75ce6466e5c8a0e5f119

If I remove the last period, the one after Always, the hash changes to:

21437c658fa3f6ff85a086a099b96d90

So what we can do is take a collection of transactions, or records (whatever our ledger is keeping track of) and make a bundle called a block. Then we calculate a hash using the data in our bundle, and by checking the hash value of the block, we can verify it hasn’t been monkeyed with.

If we include information about the previous block (its block ID, maybe ITS hash) along with the transactions in our block, we can effectively chain our blocks together – every block references the last, and so on.

So who gets to decide what the next block is?

We now have a block of transactions or records – these have been shouted out by nodes who are making or announcing transactions – and we have information about the previous block. Maybe we include some other data like the current time, or some randomly generated number too. Calculating the hash for our prospective block is relatively easy (for a computer that is).

What if we impose some arbitrary rules that the hash for our block has to adhere to? Maybe its hash value has to have 17 0’s in it. Maybe it has to start with six zeros. Maybe it has to have an even number of 1’s. Whatever. Now we’ve imposed a “difficulty” to hash generation. These rules are codified into the algorithm of the particular blockchain.

So, any node that is trying to define what the next block is now has to produce a hash that also meets some arbitrary criteria.

  1. calculate hash using block data
  2. Does hash meet the criteria? – yes: Yell “BINGO, i has next block!”
  3. no? Fiddle with block inputs, re-roll the random bits, and go to #1.

Depending on the difficulty, it could take many, many attempts to produce a hash that meets the criteria.

When a node DOES calculate a winning hash for ITS block, it literally shouts out and says, “Here’s my block! Here’s a hash that meets the criteria! I call BINGO!”. Then, a few other nodes (how many of which depend on the rules of the blockchain) double-check by ALSO calculating the hash for the block. This is called “validation”. If they agree, then the node who “did the work” gets the prize.

This is what you may have heard of as “proof of work.” The work here is coming up with block hashes that meet some arbitrary rules, which is computationally expensive. Note that to double check or validate the block’s hash is easy; you just have to do the hash calculation on the block’s content once, not thousands of times like the original miner did (because it had to find a hash that met all the criteria).

Without this proof of work, the decision of what the next block in the chain should be would come down to a consensus of all the participating nodes. If you can get all YOUR nodes, creating a majority (51%), to say, “No, no, the next block is THIS one” – which features a bogus transaction that benefits you – then you can game the system. Remember, there’s no central authority here; all entities participating in the blockchain participate equally.

Once a “mined” block is re-validated by enough peers, the network decrees: “THIS is the new block, and it contains THESE transactions that have now been validated”. The validated transactions are now considered immutable, fixed in stone, and accepted by all. Then, every node participating in mining throws its work on THIS block away, forgets about the validated transactions, and starts afresh with a new block of any remaining unvalidated transactions, and the cycle repeats.

How many miners are active on the blockchain and how many transactions are being made will determine how quickly your transaction is validated in a block on the blockchain. Depending on the blockchain algorithm, the mining pool and validation nodes participating at any given time, it could be a few minutes or it could be a few days.

Now we know what the blockchain is and what mining blocks is; in part 2 we discover where the moolah comes from.

Changelog

2024-10-10 – initial

follow –> AT tezoatlipoca AT mas.to, or AT tezoatlipoca AT awadwatt.com to follow this blorg directly on the Fediverse.