Spend Three Racks on a New Blockchain

EIN Presswire. Written by Zachary Robinson 

If you’ve been paying attention to the news any time in these past few years, Bitcoin seems like a big deal. A whole lot of people seem to be investing in it, that’s for sure, and the price is going up like crazy with no signs of stopping. Furthermore, the blockchain technology behind Bitcoin has had its own craze, becoming a tech industry buzzword on par with “machine learning” and “big data.” So, should you invest in Bitcoin? I have no idea! But I do know how it works (more or less), and if you read this article, you’ll hopefully also know how it works. Or, more accurately, how it doesn’t. 

Before I get into the weeds here, I want to clarify that this piece is going to have a larger dash of personal opinion than is typical for my column, because I’m not sure it’s possible to write about Bitcoin in a substantive way without being biased in one direction or the other. Spoiler alert: I think Bitcoin and blockchain are stupid gimmicks, at least from a technical standpoint. There are reasonable people who disagree with me. (Maybe some of those people who are reading this would be interested in writing a pro-Bitcoin opinion piece to provide a balanced perspective. Hint hint.) Without further ado, however, let’s get started.

Bitcoin is a blockchain-based currency, or cryptocurrency. Blockchains are, at the highest level, a certain way of storing data (like who has what amount of money) among a lot of different computers in a distributed manner. They do this by creating a chain of “blocks,” (hence the name), each of which is basically a self-contained package of digital data that gets added onto the end of the chain to update it. Each block has a unique address, which is the hash of everything inside the block. If you read my passwords article from October, you might remember that a hash function is a bit of mathematical gymnastics that takes in arbitrary data and produces a string of complete gibberish. The block’s data is fed into the hash function to produce a “fingerprint” of the specific block, and the chances of different blocks producing identical fingerprints are so low as to be effectively nonexistent. 

Each block that gets added onto the chain contains a number of transactions. (Technically, it just contains the hash of each transaction, in order to save space, but it’s effectively the same thing.) In each transaction, money is either transferred between different parties or created out of thin air according to a specific set of well-defined rules intended to reward people who maintain the network. We’ll talk about the creation-out-of-thin-air transactions later, but most transactions are a single movement of currency from one account to some number of other accounts. Each account is represented by a public key, which is just another long string of data. To transfer money out of my account, I have to “sign” the transaction with my private key, which is a secret number that is mathematically related to my public key in a complicated way. In short, if I sign something with my private key, everyone can mathematically verify that I have the private key (based on the signature and the public key), but nobody can figure out what the private key is. (This is called “public-key cryptography,” and this site provides a good explanation.) 

Each transaction from an account refers to previous transactions that sent money to the account in order to prove that they have the money to send. For instance, let’s say Alice (at some point) gives Bob $1. This transaction is added to the blockchain as Transaction #1. Now if Bob wants to send $1 to Charlie, he would create a Transaction #2 saying “Send the $1 that I received in Transaction 1 to Charlie.” It’s also possible to combine transaction “inputs” and have multiple transaction “outputs,” and accounts can direct the “outputs” to themselves if the inputs and outputs don’t fully add up. Let’s say at some point Alice also gave Charlie 1 Bitcoin and it was added to the blockchain as Transaction #3. Charlie could then make a transaction saying “take my $1.00 from Transaction #2 and my $1.00 from Transaction #3, and send $1.50 to Bob, $0.25 to Alice, and $0.25 back to me.” Since the entire list of transactions is public, currency can be tracked through the network all the way back to the source, making it possible to verify the validity of any transaction. 

Each block also holds the address (hash) of the block directly below it in the chain. In this way, it’s impossible to change the chain after the fact. Since any change in a block’s data would affect its hash massively, if a bad actor decided to switch things around after the fact, it would be immediately detectable as the block’s hash would change and break the “link” from the block below it. And since the hash of a block depends on the hash of the block underneath it, any changes to a block would change all the blocks above it as well.

In practice, however, it’s impossible to “change” any block anyway. Transactions and blocks exist in essentially a massive communal pool that can be added to but never removed from. This communal pool is maintained between a huge number of different nodes (computers) worldwide. When a node creates a given block or transaction, it broadcasts it to all the nodes it knows about. Those nodes then rebroadcast to all the nodes they know about, and so on and so forth until soon everyone in the world knows about the existence of a given block or transaction. If I want to connect to the network, I simply need to find any existing node and download a copy of the pool from them, and then ask them to keep me updated on any new blocks or transactions it hears about. (In practice it’s a bit more complicated, because most people don’t really need to download and parse the entire history of everything, and so there’s various caching systems and other trickery in place depending on the network. For our purposes, we can pretend that everyone has a copy of everything.)

So, if all the blocks and transactions just exist in a big pool, how do we decide which block is the “top” of the chain, or the newest block? After all, this is important not just because when we create a new block it needs to go on top of the chain, but because to figure out how much money a certain account has, we have to know which block we’re considering the “top,” so we know which transactions to count. (To find the “account balance,” we go down through the chain and find every transaction that sends money to an account and doesn’t have any other transactions in the blockchain that use it as an input.)

Well, every block except the first block (or “genesis block”) has a link to some block under it, so we just find the block that doesn’t have any links to it; that one is the one we want to add to. Except what if two people submit a new block at the same time, and so there’s two blocks that claim to be the “top” block? Well, in that case, we can just determine who we choose as the top block through some sort of agreed-upon procedure (like picking the lowest hash value) and keep building on that. That will leave some dangling blocks, but that’s okay—we can just choose whatever the longest branch is as the “top” and keep building on that. 

It’s also important to note that every other node in the network is doing exactly the same set of processing steps, and they’re all verifying that all the blocks in the chain are correct according to a common set of rules. For example, if I submit a transaction to the pool that says “take $1 from Transaction #45 and send $500 to Alice”, the nodes I sent it to would say, “Hey, this isn’t allowed!” and refuse to count any blocks that included those transactions. They also might get annoyed and stop accepting transactions from me if I kept doing that.

But there’s one kind of attack that can be conducted without causing any nodes to get annoyed: a “double-spending attack.” As the name suggests, it allows an attacker to spend the same money twice. Here’s how it works: First, the attacker purchases a product. They submit a valid transaction, which is placed into a block and confirmed by the rest of the network. The seller checks that the transaction was confirmed and gives them the purchased item. After the sale is complete, but before anyone builds on top of the block they just submitted, the attacker quickly attaches another block onto the second-highest block, and then another block on top of that—and makes sure that one of those blocks contains a transaction (perhaps just sending money to themselves) using the same inputs that they used to make the purchase earlier. Now, since the attacker’s new branch is the longest chain, all of the nodes accept it as the “real” chain and ignore the block that contained the original purchase transaction. Furthermore, the nodes agree the original purchase transaction is now invalid, because it refers to an input that’s already been taken up by the attacker’s other transaction! So, the attacker has basically “spent” some amount of money (and gotten some stuff in exchange), but according to the blockchain, they never spent that money at all!

Obviously, one of the basic requirements for a currency is that you can’t spend the same money twice, so how do we stop people from adding blocks like that? The solution is pretty simple on the face of it: make adding new blocks really hard and take a really long time, even with everyone on the network working together. To do this, we rely on those hash functions I was mentioning. Since a hash is effectively a random string of data, any small change (even by a single bit) in the block causes a totally different hash. And each block has one additional field, called the nonce, that serves no purpose other than to be included in the hash. Basically, increasing the nonce and then hashing the entire block again is like re-rolling a new random number. 

So how do we use this design to make blocks really slow? Well, to be considered a valid block, your hash must begin with a certain number of zeroes. The number needed depends on the mining speed over the last two weeks, using an agreed-upon algorithm, and is designed to keep the network confirming approximately one block every nine minutes. Computing a hash isn’t that hard for computers: it takes your laptop about a millionth of a second, and specialized computers can go much faster than that. This means that any computer can quickly verify whether a certain block has the correct hash once they claim to have found it. However, finding a hash that starts with a certain number of zeroes is extremely difficult because the hashes can’t be predicted: we have to re-generate a random hash over and over with different values for the nonce and hope that they find one where the hash happens to work out. Imagine picking a random number between one and one billion: the chance of picking a number less than one million is about 0.1% on each try. Meanwhile, right now, if I were to pick a nonce at random, the chance that I picked the correct one for the current Bitcoin block is approximately 1 in 84,387,960,000,000,000,000,000, or approximately 1 in 84 sextillion. It is, in short, the world’s worst lottery ticket.

But the only way that the blockchain works is if a whole lot of people invest a ridiculous amount of time into filling out lottery tickets really fast. These people are cryptocurrency miners, and some of them have gone to insane lengths, like building data centers in Iceland to take better advantage of cheap geothermal electricity. (Bitcoin mining in Iceland uses more electricity than its residential grid.) Why put in so much effort? Well, you might remember that I mentioned transactions that create money out of thin air; those are the rewards for miners. Whoever discovers the correct nonce for a block is entitled to award themselves a certain amount of currency for the effort — as I write this, the figure for Bitcoin is 6.25 BTC, or about $340,000, though the amount of Bitcoin will steadily decrease over time according to a predetermined formula which will reach a reward of 0 bitcoin around 2140. (In practice, miners usually mine as part of large pools, where they all contribute computing power in exchange for a proportionate share of the spoils if one of them discovers the lucky block.) For most people, their actual interaction with the blockchain network consists of dumping a transaction into the pool and little else. Transactions are packaged up into blocks and blocks added onto the chain through the mining process. Miners check the transaction pool for any transactions that haven’t been imported into the blockchain, create a block that includes them, and put it on the end of the blockchain. Transactions also usually specify a fee that goes to the miner who puts them in a block — higher fees mean a transaction will get confirmed more quickly, and lower fees might mean it takes days before a miner adds the transaction to the chain. (The average transaction fee is about $22 per transaction at the moment.) 

This lucrative reward means that miners are financially invested in the success of the network — what’s good for the price of the currency is good for the miners. It also attracts a lot of miners, which makes the network more and more secure. Messing with things via double-spending attacks requires an attacker to control at least 50% of the computing power on the network—any less, and they won’t be able to catch up to the law-abiding majority mining away on the block with the already-confirmed purchase transaction. With such a huge computing power pool, Bitcoin stands almost no chance of an attack like this. Which is cool, I guess. But all of this fancy trickery seems to obscure a rather central question: why is this even necessary?

Bitcoin, and blockchain more broadly, is an ingenious solution in search of a problem. The first non-problem that blockchain attempted to solve was currency, and specifically electronic payments. Currently, when people pay for things online, they enter their payment information, the merchant’s bank talks to their bank, and (assuming they have the funds) their bank transfers the money. (It can be a little more complicated than that, but that’s the gist of it.) Most people are pretty okay with this system. However, the 2008 paper that described Bitcoin names the following “problems” with this approach: 

While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust-based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable.

Basically, the problems with the status quo as alleged are that transactions are technically reversible (that is, there’s no guarantee that I won’t dispute a charge with my bank after receiving a service), small peer-to-peer transactions are impractical, and that fraud exists. 

The peer-to-peer transaction part obviously appears dated nowadays with the existence of a small flotilla of money transfer apps such as PayPal, Venmo, and so on, but to its credit, Bitcoin does “solve” the problem of reversible transactions. Once I transfer Bitcoin to someone, I have absolutely no chance of getting it back without the other party agreeing. It’s a little bit weird, however, that this is seen as some sort of problem. I personally like being able to dispute transactions that were made in error. If someone hacks my credit card, I can get my money back most of the time. If someone hacks a Bitcoin wallet (such as a case in which Bitcoin worth about $24.6 million at the time were stolen using phishing attacks), those transactions are, indeed, irreversible. And as seen here, Bitcoin doesn’t exactly make things fraud-proof; it just changes the potential origin point of fraud from stolen credit-card numbers to stolen wallet passwords and makes fraud less easy to deal with when it happens. 

However, these are really just side effects. The real perceived “benefit” of Bitcoin, and of blockchain technology more broadly, is a lack of necessity for any central authority that all parties involved need to trust. This is good, on an abstract level — if I could wave a magic wand and magically not have to rely on banks to manage my money, I’d do it! Theoretically speaking, my bank has a lot of power over me. The bank, or the government, could seize my assets or monitor my financial activity or whatever, and I have to trust that they’re not going to do that. I also have to trust that they won’t make more mundane mistakes like not keeping a good account of how much money I have. A distributed system, not subject to the whims of any central authority, sounds like a great idea! But here’s the problem with a decentralized system: it replaces one trusted entity (or some relatively small number of trusted entities) checking everything with everyone checking everything.

What Bitcoin gains in decentralization it loses massively in efficiency, and that’s before we even consider the cost of the lottery system I mentioned earlier. Visa, thanks to a highly efficient conventional payment processing system, handles about 150 million transactions per day, or about 1,700 transactions per second, and they claim a theoretical capacity of 24,000 transactions per second. Bitcoin, on the other hand, can handle a blistering … seven transactions per second. A single transaction also usually takes about ten minutes to go through, which isn’t ideal waiting in line at the grocery store. There are solutions in the works for this, but they’re mostly just different breeds of blockchains that sacrifice decentralization for speed (and thus eventually will probably just evolve towards the trusted-central-control model of regular banks). There’s something called the Lightning Network that might theoretically solve the problem with a sort of blockchain-based programming system, but it’s rife with vulnerabilities and still little more than a mad-scientist experiment. 

Now, if Bitcoin’s issue were only that “everyone constantly wastes a bunch of time and energy checking everything,” that would be bad enough. But as I explained above, the entire system is incredibly inefficient by design, because that’s the only way it can’t be corrupted by bad actors. Maintaining that pitiful seven transactions per second requires a total energy input of about 128 terawatt-hours per year, or roughly the electricity consumption of the entire country of Argentina. A single bitcoin transaction consumes about 600 kilowatt-hours of electricity, or enough to fully power an average American home for two and a half weeks. And all this electricity (and associated carbon emissions) is spent solely on making computers fill out lottery tickets. Meanwhile, a sensible centralized system like Visa uses about 0.1 terawatt-hours annually, for a figure of about two watt-hours per transaction. That means Bitcoin uses about 300,000 times as much electricity as Visa, transaction-for-transaction. There’s no good way around this either, because if the network doesn’t need gigantic amounts of computing power and thus gigantic amounts of electricity, then anyone with a herd of a few thousand computers can start messing things up with double-spending attacks.

These flaws I’ve outlined (particularly the low transaction rate and the fact that a single transaction costs roughly $20 in mining fees) make it pretty obvious as to why nobody actually uses Bitcoin as a currency except for relatively fringe use cases like criminal activity and ransomware payments. Nowadays, most of the investment in Bitcoin is driven by its perception as “digital gold.” However, that’s kind of a distraction for the purposes of this article, and I’m absolutely unqualified to comment on the economic aspects of Bitcoin-as-investment. This article is a pretty good discussion of Bitcoin as digital gold. 

So blockchain evidently can’t really be used as currency, at least in the sense of “something you use to buy and sell things on a regular basis.” Aside from a very small number of people who are irrationally terrified of trusting their bank to hold their money for them, most people prefer to have a centralized trusted system instead of waiting ten minutes to buy a latte. So what is blockchain good for? Well, it’s a good idea to keep track of things across a large number of distributed nodes if you are willing to massively sacrifice speed, energy usage, and efficiency in exchange for not needing a central trusted database. I’d provide examples, but I genuinely can’t think of any use cases with those specific constraints. The fact of the matter is that contrary to the thinking of a certain breed of paranoid Silicon Valley types, trust is not inherently bad — and everyone assuming that everyone else has it out for them all the time unless cryptographically proven otherwise is no healthy way to live except for specific breeds of cybersecurity researchers.

That said, there are lots of very smart people desperately trying to figure possible uses in order to make their investment in the crypto market worthwhile. I’m sure it’ll be all over the news if they come up with a solution to any problem that wasn’t already solved by a properly designed “conventional” system. (And to be clear, the mere fact that someone’s started a company that uses blockchain to provide some service doesn’t mean that blockchain actually does a better job.)  To be clear, I don’t claim to know everything — there’s a chance that blockchain technology is in fact a game-changer when applied to solve a societal problem that we don’t even know we have, and if that happens, everyone has my full permission to send me links to this article ten years from now and point and laugh at how stupid I was. But as of right now, based on what I know, it’s mostly just a neat computational trick.

If you have any further questions or think that I got something wrong, feel free to email me at zrobins2@swarthmore.edu. You can also DM me on Instagram @software.dude. Or write that opinion piece.

Some final notes:

• Obviously, the fact that everyone’s transactions are public is a security flaw: the way this is usually dealt with is that public keys are anonymized, so it is possible to see that someone sent a transaction to someone else, but not who it was. Since someone needs your private key to send money to you, however, there are also services that “mix” bitcoin — you send a certain amount of currency to them, they “mix” it into a big pot with other people’s currency, and then send an equivalent amount of currency from that pot to a different address that you also control. I’d argue that this has exactly the same issue with a trusted central entity as giving your regular money to a regular bank, but what do I know?
• The “84 sextillion” figure is based off of the current Bitcoin hashrate, which as of this writing is 156.274 million trillion hashes per second. I then multiplied that by the number of seconds in an average block mining time of nine minutes.
• I calculated the energy per transaction based off of the 128 TWh/year figure, divided by the number of seconds in a year, divided by seven transactions per second. The annual home electricity consumption is from that same WolframAlpha calculation.
• Visa’s energy consumption is a bit harder to pin down, but according to their 2017 corporate responsibility report, they used 680,560 gigajoules of energy that year, of which 54% (367,502 gigajoules, or 102.084 gigawatt-hours) went to their data centers that actually process the payments. Then I did the same calculation as last time to get the electricity per transaction. If anything, this comparison is unfair to Visa, as most of their data center electricity is probably used for things like their website, internal business stuff, or fraud prevention instead of just payment processing. 
• The article about solutions also brings up the point that some of Bitcoin’s transaction speed limitations are self-inflicted, but it does the math and it turns out that the theoretical limit of how fast transactions of a certain size can propagate through the network is at about 200 transactions per second, or nowhere near enough.
• A quick note about NFTs, or Non-Fungible Tokens, as those have been in the news lately: the concept of an NFT is pretty simple. Because it’s possible to trace the path of a single bitcoin or fraction thereof through the blockchain, just slap a label on it saying “whoever owns this coin owns this specific bit of artwork.” That’s really all there is to say about it from my perspective. Obviously, it’s ridiculous that people would pay $2.5 million for a digital certificate saying that they “own” the first tweet on Twitter, but it’s arguably less ridiculous than paying $150,000 for a banana duct-taped to a wall, so who’s counting.
• Special thanks to Andrew Merrill, my high school Comp Sci teacher (and, incidentally, a Swarthmore alum) who first taught me about blockchains about three years ago in a CS topics class.

The opinions expressed in this article are solely the author’s