8 stories
·
0 followers

On the Dangers of Cryptocurrencies and the Uselessness of Blockchain

6 Comments and 12 Shares

Earlier this month, I and others wrote a letter to Congress, basically saying that cryptocurrencies are an complete and total disaster, and urging them to regulate the space. Nothing in that letter is out of the ordinary, and is in line with what I wrote about blockchain in 2019. In response, Matthew Green has written—not really a rebuttal—but a “a general response to some of the more common spurious objections…people make to public blockchain systems.” In it, he makes several broad points:

  1. Yes, current proof-of-work blockchains like bitcoin are terrible for the environment. But there are other modes like proof-of-stake that are not.
  2. Yes, a blockchain is an immutable ledger making it impossible to undo specific transactions. But that doesn’t mean there can’t be some governance system on top of the blockchain that enables reversals.
  3. Yes, bitcoin doesn’t scale and the fees are too high. But that’s nothing inherent in blockchain technology—that’s just a bunch of bad design choices bitcoin made.
  4. Blockchain systems can have a little or a lot of privacy, depending on how they are designed and implemented.

There’s nothing on that list that I disagree with. (We can argue about whether proof-of-stake is actually an improvement. I am skeptical of systems that enshrine a “they who have the gold make the rules” system of governance. And to the extent any of those scaling solutions work, they undo the decentralization blockchain claims to have.) But I also think that these defenses largely miss the point. To me, the problem isn’t that blockchain systems can be made slightly less awful than they are today. The problem is that they don’t do anything their proponents claim they do. In some very important ways, they’re not secure. They doesn’t replace trust with code; in fact, in many ways they are far less trustworthy than non-blockchain systems. They’re not decentralized, and their inevitable centralization is harmful because it’s largely emergent and ill-defined. They still have trusted intermediaries, often with more power and less oversight than non-blockchain systems. They still require governance. They still require regulation. (These things are what I wrote about here.) The problem with blockchain is that it’s not an improvement to any system—and often makes things worse.

In our letter, we write: “By its very design, blockchain technology is poorly suited for just about every purpose currently touted as a present or potential source of public benefit. From its inception, this technology has been a solution in search of a problem and has now latched onto concepts such as financial inclusion and data transparency to justify its existence, despite far better solutions to these issues already in use. Despite more than thirteen years of development, it has severe limitations and design flaws that preclude almost all applications that deal with public customer data and regulated financial transactions and are not an improvement on existing non-blockchain solutions.”

Green responds: “‘Public blockchain’ technology enables many stupid things: today’s cryptocurrency schemes can be venal, corrupt, overpromised. But the core technology is absolutely not useless. In fact, I think there are some pretty exciting things happening in the field, even if most of them are further away from reality than their boosters would admit.” I have yet to see one. More specifically, I can’t find a blockchain application whose value has anything to do with the blockchain part, that wouldn’t be made safer, more secure, more reliable, and just plain better by removing the blockchain part. I postulate that no one has ever said “Here is a problem that I have. Oh look, blockchain is a good solution.” In every case, the order has been: “I have a blockchain. Oh look, there is a problem I can apply it to.” And in no cases does it actually help.

Someone, please show me an application where blockchain is essential. That is, a problem that could not have been solved without blockchain that can now be solved with it. (And “ransomware couldn’t exist because criminals are blocked from using the conventional financial networks, and cash payments aren’t feasible” does not count.)

For example, Green complains that “credit card merchant fees are similar, or have actually risen in the United States since the 1990s.” This is true, but has little to do with technological inefficiencies or existing trust relationships in the industry. It’s because pretty much everyone who can and is paying attention gets 1% back on their purchases: in cash, frequent flier miles, or other affinity points. Green is right about how unfair this is. It’s a regressive subsidy, “since these fees are baked into the cost of most retail goods and thus fall heavily on the working poor (who pay them even if they use cash).” But that has nothing to do with the lack of blockchain, and solving it isn’t helped by adding a blockchain. It’s a regulatory problem; with a few exceptions, credit card companies have successfully pressured merchants into charging the same prices, whether someone pays in cash or with a credit card. Peer-to-peer payment systems like PayPal, Venmo, MPesa, and AliPay all get around those high transaction fees, and none of them use blockchain.

This is my basic argument: blockchain does nothing to solve any existing problem with financial (or other) systems. Those problems are inherently economic and political, and have nothing to do with technology. And, more importantly, technology can’t solve economic and political problems. Which is good, because adding blockchain causes a whole slew of new problems and makes all of these systems much, much worse.

Green writes: “I have no problem with the idea of legislators (intelligently) passing laws to regulate cryptocurrency. Indeed, given the level of insanity and the number of outright scams that are happening in this area, it’s pretty obvious that our current regulatory framework is not up to the task.” But when you remove the insanity and the scams, what’s left?

EDITED TO ADD: Nicholas Weaver is also adamant about this. David Rosenthal is good, too.

Read the whole story
chrismo
880 days ago
reply
#tech
Share this story
Delete
5 public comments
bronzehedwick
880 days ago
reply
Crypto is one of the rare cases where if we burn it to the ground it will help our species survive.
Tarrytown, NY
PaulPritchard
880 days ago
reply
"This is my basic argument: blockchain does nothing to solve any existing problem with financial (or other) systems. Those problems are inherently economic and political, and have nothing to do with technology. And, more importantly, technology can’t solve economic and political problems. Which is good, because adding blockchain causes a whole slew of new problems and makes all of these systems much, much worse."
Belgium
ReadLots
880 days ago
reply
If we can just move all of the fraud into the blockchain, maybe then it can have purpose - keeping the scammers busy in crypto and leaving us outside of it alone.
acdha
880 days ago
reply
Green's “rebuttal” was disappointingly weak — to be honest, I read it expecting the end to be that he'd picked up some lucrative consulting work from a cryptocurrency company.
Washington, DC
GaryBIshop
880 days ago
reply
Well said!

Introducing zq: an easier (and faster) alternative to jq

1 Comment

If you’ve found the (excellent) jq tool for working with JSON a bit unwieldy… check out zq and see if you like its API any better. I wouldn’t put too much weight on the faster aspect, though:

We will cover zq’s performance in a future article, but to cut to the chase here, zq is almost always at least a bit faster than jq when processing JSON inputs

Almost always at least a bit faster is not something you’re likely to notice in practice.

Discuss on Changelog News

Read the whole story
chrismo
938 days ago
reply
#tech
Share this story
Delete

How DALL-E 2 actually works

1 Comment

Curious how OpenAI’s new DALL-E 2 manages to generate impressive artwork from short natural language prompts? This article breaks down the steps then focuses in on how it does the image generation step.

How DALL-E 2 actually works

Discuss on Changelog News

Read the whole story
chrismo
945 days ago
reply
#tech
Share this story
Delete

Automation is the serialization of understanding

1 Comment

What you’re about to read is a fancified excerpt from Ship It! #44. You should read the original transcript or listen to the entire conversation for more context. To set the stage, this is Kelsey’s response to Gerhard asking what the biggest takeaway should be from their conversation.


The reason we find ourselves as practitioners (as an industry as a whole) constantly migrating between different platforms, journeys, and digital transformations…

We do this because I don’t think we ever understood the fundamentals.

The fundamentals are very clear. If you’re thinking about application delivery, for example, we know what the fundamentals are.

Ideally, we’re versioning the source code we write, and using tools that enable us to build and package applications in a reproducible way. 15 years ago maybe you were just creating WAR files or ZIP files. Maybe you were sophisticated and you were creating RPMs or DEBs so you could use a package manager. Those practices have always been good ideas. Packaging is a by-product, or the artifact, of assembling code and your dependencies, and getting your applications ready for deployment in a repeatable way. If you did that 15 years ago, adopting something like Docker is not hard to do. You say…

“Okay, we’re gonna take the existing RPM and use it to create a container image. Instead of running yum install on a server to install the RPM, we can now call the same command from a Docker file, and produce a container image.”

It’s just another packaging step, and if you decouple packaging from deployment, then you get the ability to change just the last mile.

So even if you’re just using RPMs today, you can layer on container packaging. Even if you’re using something like Puppet to deploy those RPMs, once you have a container image, you can actually swap out the Puppet step for the Docker step, and it works.

But you have to understand the fundamentals and the boundaries between these concepts.

I think as an industry we’ve been pushing…

Automate. Automate. Automate.

And we haven’t been saying…

Understand. Understand. Understand.

Because if you understand what you’re doing, you can automate if you want to.

Because if you really have a clean process that says…

“Okay, we’ve automated the build process of a Docker container image, and look, we don’t really have more than two environments.”

So the QA process can look like this…

“Docker run this container image. It works. We go to production. Docker run the same container image. It works.”

And maybe that’s all your team needs to do! And look, that’s okay. But I think understanding allows us to make that decision, and then we can decide what automation tool is the best for the job.

These fundamentals can be applied using different tools. The tools are not the fundamentals. It’s the ideas and concepts that we have been talking about today.


Dig this post? Subscribe and check out what Kelsey has to say about the power of protocols. 👇

Subscribe to our YouTube channel for more clips like this, live show recordings, and more ✌️

Discuss on Changelog News

Read the whole story
chrismo
951 days ago
reply
#tech
Share this story
Delete

Zero downtime schema changes in PostgreSQL

1 Comment

Schema changes are usually critical operations to perform on a high volume database. One thing off, and you are looking at an outage. pg-osc makes it easy and safe to run any ALTER statement on a production database table with no locking.

Discuss on Changelog News

Read the whole story
chrismo
960 days ago
reply
#tech
Share this story
Delete

Why we don't use a staging environment

1 Comment

The Squeaky team goes from dev straight to prod (same here), but many people advocate for (and use) staging or other “pre-live” environments instead.

While there are obvious benefits to deploying to different environments, at Squeaky we’ve decided to take a different approach. We only have two environments: our laptops, and production. Once we merge into the main branch, it will be immediately deployed to production.

Perhaps that sounds unusual, but so far it’s outweighed the benefits of pre-live environments, and we believe it’s helping us to ship faster, and lower the number of issues on production. So, I thought I’d write this post to share why we think it works, and why you should consider it too.

Discuss on Changelog News

Read the whole story
chrismo
960 days ago
reply
#tech
Share this story
Delete
Next Page of Stories