Hacker News new | past | comments | ask | show | jobs | submit login
A Current List of Use Cases for Ethereum (medium.com)
119 points by sethbannon on May 23, 2016 | hide | past | web | favorite | 43 comments

I'll say it bluntly, because I know some people here really like Ethereum. Ethereum sucks. (Note: I don't want it to...)

1. No checksums on user's accounts. BTC has had checksums from get-go. Ethdevs think that 0xdeadbeef hex keys are just fine. Except that one-off you did (or added a null/0 at the end) just dead-ended your transaction and lost money in the 'chain. Gone for good. Forever, nada, zilch.

2. Blockchain itself isn't checksummed. ?! When you download the chain to do the proof of work calculations, there's no guarantee that a 1-off error didn't creep in the chain you're working with. What's that do? It invalidates every 'work' you do. You're spinning cycles with 100% chance of NO payout.

3. There's no way to auto-pay an account's own gas costs. If I'm a dApp maker, I want to pay to submit the program. Cool. Now if User A wants to execute my app, they have to pay gas (or percents of eth coin). That's a huge suck. Massive suck. I want this cost taken care of so users aren't nickel and dimed to use the damned thing. Right now, nickel-and-dime it is.

4. Software is bad alpha quality. Search for "lost wallet ethereum", and you'll see thousands of people with lost coin. Many errors are the above one-off errors, others are code badly interpreted to lose coin, and others were import errors on the Kickstarter coin purchase.

5. The "Smart Contract" code is completely trapped within the Eth system. I can't query a website and check data from there, nor can I generate random numbers, nor can I do anything that isn't explicitly on the blockchain. That directly implies that gambling apps and similar are completely deterministic and knowable. Effectively, gambling on Eth isn't a random chance with an edge to the house; it's a mathematical guarantee that the house wins, and you lose.

Until these flaws are fixed, this sstem isn't worth putting any more money in than you're willing to lose. Because loss is a distinct possibility with the sheer number of bugs and bad code there is.

Disclaimer. I have skin in the game. I've been developing on the platform since the Frontier launch and I have some Ether holdings.

1. Checksums are available via the mechanism in https://github.com/ethereum/EIPs/issues/55

2. I don't have any experience mining. Maybe someone else can answer this.

3. If I recall correctly, this is being fixed in Serenity. Transaction validity will no longer require ether to be submitted with the transaction allowing miners to accept transactions that are paid for during their execution.

4. Ethereum only left Alpha/Beta on March 14th 2016, roughly two months ago. Until then there were clear warnings posted that there were likely to be bugs. I'm not aware of anyone losing money due to protocol errors. The losses I've read about are predominantly user error and errors in 3rd party software.

5. This seems like a clear lack of understanding of the intentional design of the system. If you could directly make HTTP queries from smart contracts it would be impossible to reach consensus on what the result of code execution was because two clients could get two different responses from the same query. Everything that the EVM executes has to be 100% deterministic. Take a look at http://www.oraclize.it/ for an example of how communication with the outside world can be done.

I hope that clears things up.

Account number checksums have been added, by using capitalization. 0xdEAdBeEF will be flagged invalid if the capitalization isn't correct.

Windows 1.0 had a vastly larger list of why it sucked. So did the early web, early versions of DOS, early hobbyist PCs, early microprocessors, heh, perhaps even von Neumann's IAS machine.

Use cases embody the most obvious value potential of a technology. If the various "it sucks" obstacles can be bridged, the value potential of the use cases gets realized.

So it follows that if the use cases are valid and highly valuable, and the problems can theoretically be bridged (at even a high cost), then there is very good chance that the problems will be addressed in the near future.

Well, addressed enough (pointing to Windows 3.1).

If you were saying this about blockchains in general, then I'd agree that this is a baby step in some awesome engineering.

But I'm talking explicitly about Ethereum. In that case it is awful, bad, no good software. I'm comparing it to our other proof-of-concept that seems to work rather well and avoid all those pitfalls: Bitcoin.

Bitcoin has been in production for seven years. In its first year it wasn't nearly so polished.

I think checksumming of addresses was very early there, at least it was in late 2010 when I first used bitcoin. It is quite basic thing and easy to implement. It should help people avoid losses and possible problems caused by trivial mistakes.

They were hoping a name registration scheme would catch on and people would largely use that instead of using addresses directly. It hasn't happened so far, so now they've added checksums (using capitalization).

To clarify, "they" here means Ethereum. Ethereum has checksums.

In fairness, Windows 1.0 wasn't advertising itself as the future of finance or using the inability of third parties to intervene to retrospectively fix errors as its chief selling point.

BOOM! You called it. Further, an interpreter that works, basic checksumming/hashing for integrity of most important data... things like this are mandatory minimums for something like this. I mean, the academic prototypes I find being done by undergrads often have more than that. These people's game-changing platform doesn't have the basics that undergrads throw together in weeks using widely available libraries as building blocks?

Doesn't inspire confidence.

Undergrads don't start with a formal spec and develop four independent client implementations simultaneously in different programming languages.

No, they develop at least one with minimum, basic features their formal spec depends on. Then another. Then another. Then another. Then, they have four.

Alternatively, several of them develop several components in parallel with constant communication to keep them in sync and with a spec. These have the minimum, basic requirements.

Then, there's security-focused products that... going by your statement... start with a formal spec that ignores basic, integrity checks then develop four implementations simultaneously also missing basics. "Not a great plan." (Tony Stark)

Can some explain how a block-chain scales? If every transactions needs to be stored on all market participants computers doesn't that blow up pretty quickly?

At present, as far as I know all of the scalability plans for Ethereum are theoretical. That said the plan thus far is:

Light Client Support allows for running a node that does not sync the full chain, but rather downloads and verifies only the small parts necessary to send transactions and read state.

Proof-of-Stake replaces Proof-of-Work which opens up options for things like parallelization.

Sharding is a plan to split the blockchain into many smaller chains that are all linked but operate largely independently, allowing for horizontal scaling of the network. Transactions within a shard are synchronous. Transactions across shards are asynchronous.

Think of it as an append-only database with 512 KB chunks. Once a chunk is written, it has a hash associated to it.

The next chunk will have the first line to the previous hash, showing data continuity.

Yeah, it's more complicated than that, but that's the raw essential basics.

The basic answer is that transactions are small and not everyone needs to store the whole chain. Even now storing the whole blockchain is slightly 'enthusiast'. I think it might go more in this direction in the future, but at the same time the cost of storing the entire blockchain on an SSD and the bandwidth to sync with the bitcoin blockchain are nearly trivial (the blockchain stands now at 75GB).

I think the likely evolution in the future is that most people won't store the blockchain, but that there will be multiple separate currencies and enthusiasts will store the blockchain for the ones they use or are interested in.

If you want a challenge and can contribute, some details are:

EIP 105 (Serenity): Binary sharding plus contract calling semantics


Very technical open discussion here:


I believe they also have weekly Google Hangout on Mondays.

There are a number of proposals. In bitcoin, sidechains (separate blockchains that get anchored to the main chain) are oft-touted, as is the lightning network. The idea is that only the most important / highest value transactions make it onto the main blockchain.

There are other approaches as well. Most actors don't need all past transactions- just the valid spendable outputs. Old txs could be pruned. You can also apply ideas from regular databases, like sharding.

It doesn't. That's why they're dumb and will never succeed. You can only hand wave it away while raking in the VC money for so long...

Where is the VC money coming from in a crazy we funded project?

Just keeping the storage requirement down is pretty easy, at least on Ethereum. One of the clients (the Rust version) already prunes old history.

A more difficult task is making it so nodes don't have to see all the ongoing transactions. Ethereum is attempting that with a sharding scheme.

70gb in 7 years.. including cryptographic witness which is soon going to be segreted..

There's a stackexchange with technical answers to most of these questions, such as:


For #3, an introduction is:


and the improvement proposal is: https://github.com/ethereum/EIPs/issues/28

For #1, there are checksums now, but the more interesting question and challenge is how would a decentralized registry/DNS be designed, that has reasonable anti-incentives for squatters?


Regarding the gambling in your number 5, wouldn't the house generate a secret number (as randomly as it wishes), encrypt it, post it to a gambling contract, let people place bets on it, and finally reveal the decryption key to the contract?

> 5. The "Smart Contract" code is completely trapped within the Eth system. I can't query a website and check data from there, nor can I generate random numbers, nor can I do anything that isn't explicitly on the blockchain. That directly implies that gambling apps and similar are completely deterministic and knowable. Effectively, gambling on Eth isn't a random chance with an edge to the house; it's a mathematical guarantee that the house wins, and you lose.

Wouldn't the proof of work hashes be a good distributed source of entropy?

Yes, and there are gambling apps that use the block hashes. Miners have the option of throwing away blocks they don't like, but are likely to lose the block reward if they throw away a valid block hoping to find a better one. So as long as it's not a huge payoff, it works fine.

Possibly, but I can have my client delay-submit successful work as to game the system.

And when Ethereum switches to Proof-of-Stake, bad shit will happen. (Mainly, its when you wager eth coin on the fact you have a correct-work. Its not hard to see the badness from that...).

Not an expert, and this is limited in what you could use it for, but for gambling purposes, couldn't this be dealt with by using the next X hashes after the bet is placed, where X is a large enough number that the likelihood of the better being able to produce that many successful blocks in advance is nil.

So, at the simplest, you take a bet, and then use the next two hashes for your random seed to get a result. Even if a miner found a solution for the next hash and withheld it long enough to make a bet, he wouldn't have enough information to do better than random chance. And as I understand it, the entire blockchain relies on the fact that one miner shouldn't be able to generate two blocks faster than the rest of the mining pool. Increasing from two grants even greater certainty.

Of course, the trade off here is that you have to wait for X blocks to be generated after a random number is requested and before being able to use it. So, your gambler has to sit around a bit to find out if they win, rather than instant feedback. (Of course, for gambling, you can hide this with some pretty animations of a roulette wheel, dice, horses running, etc.)

I believe that's open to tampering by miners (more easily than a sybil attack, IIRC).


I'm rebuilding an old hackathon project, ChainProof, to use Ethereum. It's basically a service that lets people submit facts about themselves and automated or trusted notaries verify the information and vouch for it.

DAOs and smart contracts would be able to use the knowledge in really cool ways. A DAO could requires participants to be KYC verified, limited to college students, be accredited investors, pass a background check, etc.

Neat thing is that once those checks are done, it'll be attached to their Ethereum identity so they don't have to redo the verification for every compatible service or DAO.

Ethereum might have some weaknesses at the moment but it's a lot more exciting than Bitcoin.

Not to overhype the potential of Ethereum, but one can also go beyond the obvious "next steps" and start to see entire new avenues that a technology opens up.

I say "start to see" because it is very hard to predict how one particular avenue of unforeseen capability might lead to success! In the early web, there were many of these kinds of use cases talked about and a lot of effort was made to bridge the technological gaps to get to the anticipated capabilities. One use case that stands out in this regard is ecommerce (before secure web connections existed).

But the real interesting advances are those that are not obvious from the get-go! These stem from creative modifications, and of course the very long slog of trying to realize the potential of those modifications. It takes confidence in the people who do the work, and it takes many, many failures.

Social software stands out as an example of this long slog that ends in success.

It took more than a decade of incremental advances -- from forums and chat rooms in the early web to the blogging scene in the early 2000s -- to get to where it stands today: a set of widely-implemented and widely-understood capabilities.

So definitely consume that list of use cases, and understand the near-future better.

But if you're interested in assessing and leveraging the full potential of Ethereum, definitely learn about its basic capabilities, then open up your imagination. You might see a glimmer of what could be, and perhaps be a part of getting there.

I am missing something?

1. "Gold Investing"

>No brokers, no banks, no fractional reserve, near-zero fees, immediate, and secure

You need a vault, and also you need that the entity controlling access to the phisical stuff (i.e. gold) is willing to comply.

2. "Crowdfunding"

The "smart contract" will need "gas" to run, so there's a "fee" to be payed, not 0%.

Digix: "Gold in tokenized form on the Ethereum blockchain..."

Digix: "[ANN] Gatecoin Hacked, only BTC and ETH is currently affected, all DGD tokens are safe."[1]

OK, do we have a use case that works?

[1] https://medium.com/@Digix

That part caught me, too. First, I wonder how they were getting it backed by gold and seemlessly. Second, they said the gold investments are safe if they collapse. So... somehow the original source will know for sure that it's yours and easily convert it back to cash? Have any idea what they're using on gold side to do that?

It was harder a long time ago when I looked into gold investments as the digital ones were shady enough that I was concerned with money laundering investigation. Getting caught in theirs, that is.

It's a lot easier to find prior art that new technology can improve on once you've found a good metaphor for it. Here's the one I use:

Scribes once wrote the history that coordinated societies on scrolls. Ethereum is a digital scroll in the cloud that any app can write permanent entries to. Lots of social problems became much easier to solve once we had written records with a trusted source of truth, and now we can have trusted records for literally any interaction between people that we're willing to make public. As a bonus, there are no scribes we have to trust because the economics of blockchains allow us to hire arbitrary scribes off the street who lose money if they attempt to manipulate records. All individuals can interact as equals without an overseer.

The social problem I'm using Ethereum to solve is our drastic underinvestment in public goods—goods that are non-rivalrous and non-excludable, so they're hard to get people to pay for. My hypothesis is that we can put contributions on a digital scroll to unite people in purpose, and perhaps we can build a society that checks the scroll to reward people who have contributed to public goods.

Developers who know how to wield these digital scrolls can have as much impact on their society as those who controlled the physical scrolls, but since we can't force people to acknowledge our scrolls, we can only have an impact if we build interactions people actually want to adopt voluntarily. Digital scrolls tie our hands—overt attempts to control users will be routed around.

The most prevalent seem to be pyramid schemes and gambling apps.

Each of these use cases can be done with bitcoin too. Pick any and I'll tell you how if you couldn't figure out.

How do you reach "off-chain" with ethereum? For example, if I invest in gold with Digix, how do I know that I can actually get my gold if Digix decides not to give it to me?

Btc is cool because it requires nothing but the network. The moment you require counterparty (as is the case in the examples), you might as well let the counterparty control the 'logic' of the case as well.

Each of these use cases can be done with bitcoin. Pick any and I'll tell you how to do it if you couldn't figure it out.

Wow this is REALLY helpful thank you. I can just link to this now when people ask me what the point of Ethereum is.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact