Miners Aren’t Friends

https://blog.keep.network/miners-arent-your-friends-cde9b6e0e9ac

by vinnyglennon • 9 years ago

394 249 9 years ago

blog.keep.network

nspassov• 9 years ago

To my limited understanding of Ethereum and Bitcoin, the network already has rules in place to punish nodes that misbehave or cheat. In the case of Bitcoin, that is part of layer 1 so it is independent of any application layers and thus it should always be at the core of the network.

With PoS cheating is likely to become a bigger issue [1], since with PoW the miners who get punished will have wasted their time and electricity.

Would be great to hear comments from more knowledgable people.

[1] https://twitter.com/hugohanoi/status/951762596255838209

thescriptkiddie2• 9 years ago

Miners who cheat will be punished even more under PoS than under PoW, provided they are caught. If you get caught mining a "bad" block under PoW, you lose only the work that went into that block. If you get caught mining a "bad" block under PoS, you lose everything you staked on that block. It's almost as if you have mining hardware that doesn't use any electricity, but self-destructs if you misbehave.

RoboTeddy6• 9 years ago

Certain kinds of misbehavior are punished. If you mine an invalid block, everyone will reject it, and you won't get any reward (you burnt electricity and hardware time for nothing). It works the same in PoS -- if you mine an invalid block, then (depending on the protocol) either your entire security deposit will be destroyed (ouch!) or no one will build atop your fork and you won't have any mining reward (same as PoW).

Block validation can only enforce certain kinds of rules, such as:

* People can only spend outputs they have the private key for

* You can't spend an output that has already been spent

* The block reward has a predetermined size

There are other kinds of rules that we don't know how to enforce yet. For example, we might want the rule, "Always create blocks with the top n transactions that offer the highest fee per byte, out of all the new transactions you've learned about". The trouble is that we don't know how to prove that a miner has learned of a transaction over the network. (Maybe there was a network partition, or maybe their internet connection died for a minute-- how can we tell between those conditions, and the case where the miner learned of but ignored a transaction?)

The "misbehaviors" listed in the article fall into this category: things we might like to make rules against, but don't know how to (or know how to, but haven't bothered yet).

barbegal6• 9 years ago

Proof of stake doesn't work in practice unless we can find a source of randomness that is globally available, non-influencable and everyone can agree on [1]. At the moment, that source of randomness is completely elusive. It might be possible to create a random source from some form of binary astronomical event which can be widely verified but it would have an incredibly low bit rate of new randomness. One possible candidate is randomly nulling pulsars [2]. Unfortunately, the equipment required to observe this phenomenon is probably not widely available outside of large observatories. Having said that the costs would still be lower than the energy costs of the Bitcoin network.

[1] http://www.truthcoin.info/blog/pos-still-pointless/

[2] https://arxiv.org/abs/1706.05407

konschubert5• 9 years ago

How about using stock markets?

They are of course vulnerable to some amount of manipulation, but with a good algorithm that could be rendered sufficiently costly to become impractical.

RoboTeddy6• 9 years ago

Can imagine a protocol for generating randomness to some arbitrary security level (at the expense of locking up security deposits):

(1) Anyone can decide to become a 'randomness provider' by putting up a large security depsoit

(2) Every epoch (some number of blocks), each provider chooses a private random number and commits to it by publishing its hash

(3) During the next epoch but, each provider publishes the random they committed to earlier.

(4) xor together all the random values. The result is a pseudorandom number everyone can agree on, and which should be sufficiently good for many applications include PoS selection

If any provider fails to publish the random number they committed to, they lose their security deposit and there is no random value provided for the associated epoch. The process starts over.

If you're worried about bribing attacks over all providers, recognize that all we need is a single altruistic provider to keep the system safe. Altruistic behavior may be rare compared to selfish behavior, but I think we can usually rely on its nonzero presence.

If you're still really worried that collusion could be going on amongst ALL randomness providers, just become a provider yourself.

It's possible for a provider to wait for all other providers to reveal their values, and then privately determine whether or not the final random value would be favorable to them; they then have the option of canceling the epoch by keeping their private value hidden and losing their security deposit. This option (in combination with a particular application, and the size of the security deposit of providers) puts a bound on what the random value can be safely used for (e.g., if it's for a lottery, the expected value of another truly random swing at the jackpot has to be lower than the value of a security deposit).

konschubert5• 9 years ago

Here is how I understand the argument made in the first link:

If you give people a certain block reward, say 1$ per year, then the capital they are willing to invest to gain that reward will be 1$ divided by the worldwide rate of capital returns at the given risk level.

The argument is that it doesn't matter if we are dealing with capital that is locked away in mining hardware + lost as electricity or in a smart contract. The total amount of "economic work" locked away will be the same.

I think that's correct. Proof of stake is not cheaper for the short-term economy than proof of work.

But what about the long term? 100 years? The kind of time frame that investors don't worry about, but we as mankind should?

I guess what I'm saying is that locking away capital today maybe has less long term damage than wasting extreme amounts of energy.

mhluongo7• 9 years ago

Publicly verifiable randomness is possible without relying on astronomical events. Check out threshold relay by the Dfinity team (which we're porting to Ethereum), or RandHound and RandHerd [1].

1 - https://eprint.iacr.org/2016/1067.pdf

konschubert5• 9 years ago

does this apply both to blockchain-style proof of stake and BFT - style proof of stake?

hashkb• 9 years ago

Sounds like insider trading is built in fundamentally. Should help legitimize ETH on Wall Street.

throthro• 9 years ago

COuld you elaborate on builtin insider trading?

JohnJamesRambo2• 9 years ago

Almost all miners use a mining pool so wouldn't have access to these tricks. The pools on the other hand...

I used to have an Ethereum mining operation, before it became unprofitable to do so. It was one of the most fun ventures of my life. All the cards and enormous heat and fans exchanging outside air in. It felt like I was part of something futuristic and new, solving problems I had never had experience with before. I miss it very much, I wish it could have gone on forever.

1337biz• 9 years ago

Care to share some insights into the economics of running it and how it became unprofitable?

joshvm• 9 years ago

The economics are simple - how much power do you use vs how much money you make per unit time. As a miner you're banking on the increase in difficulty correlating with an increase in price. Ethereum mining difficulty plummeted back in October, flatlined for a bit, and has been slowly on the rise since December.

There is limited resale value in the cards (depreciation etc), but even after PoS hits there will be enough mineable things that selling them off wouldn't be necessary. Love or hate it, you could use a service like Nicehash.

It becomes unprofitable if the difficulty spikes, but not the value, so your hardware takes a long time to mine little. Often this happens between new technology generations, like when ASIC miners made GPU miners unusable for Bitcoin.

Right now Ethereum is still quite profitable to mine. I have a bunch of GTX1060's with a combined hashrate of 100MH/s running on an EthOS system. That's enough to earn between 0.35-0.4 ETH a month at the moment. The power usage is around 300W with some twiddling - around £25-30 per month.

You also have to consider speculative value of the coin. Suppose you were mining 1ETH a month back in January '17. Your monthly payout (about $30) would have barely covered electricity, but now 1ETH a month is practically a minimum wage salary. You need to be honest with yourself why you're doing it - are you making money to spend today or are you holding?

JohnJamesRambo2• 9 years ago

I just exited when the calculator at mycryptobuddy.com (which calculates in difficulty increases) indicated that profitability would be miniscule and not much over electricity costs very soon. It cannot account for price increases in Ethereum, but if you are using that to stay profitable it is almost always better to invest in the coins themselves. I sold all my gear and cards while their price was high and invested all the money into cryptocurrency. The gamble has paid off handsomely, I make more from crypto investing than from my job now. It has allowed me access to things I never could have dreamed of, but I still miss walking in my Ethereum mine and feeling the over 100 deg. temps and the instant sweat and all the noise. I miss all the network cables and blinking lights and thinking about the new network I was helping to secure. Trading and investing can't hold a candle to it, but the money is better.

doctoboggan3• 9 years ago

If you have modern cards you can still mine with one of the services that find the most profitable algorithm for you.

I use NiceHash and have historically made about $2/day per GTX1070. This past month though I've been making more that double that.

EDIT: Use this site to find out if your cards will be profitable considering your energy costs: https://www.nicehash.com/profitability-calculator

I do want to leave one important caveat. NiceHash was recently hacked and anyone who left their money in their online NiceHash wallest lost it. They recently came back online and claimed they have a plan for paying people back and will give more details at the end of this month. That being said they have paid me for my mining since the hack. If you do use them I'd recommend withdrawing to wallets you control as often as possible.

prepend• 9 years ago

Are you mining independently? Or as part of a pool?

corford12• 9 years ago

I don't understand the economic argument for personal mining (I totally get it from a fun, geeky PoV if making money isn't the primary goal - it's how I got started in crypto).

A GTX1070 costs about $800. At $4/day, it will take you 200 days to make back your principle (ignoring power costs, difficulty scores going up etc. - in reality it will obviously take you even longer to cover your costs).

If you had put that same $800 in to buying ETH (picked because it's a relatively safe, "boring" coin) on 1st July, 200 days later (or 7 months) it would have been worth $2,140 (yielding a $1,340 profit per card equivalent cost invested - note I'm using ETH price on 1st Jan 2018 and not including the recent growth to a new all time high). And the profit will likely x5 (or more) this year if you hold on to your ETH.

joosters2• 9 years ago

How much money did you lose from the NiceHash 'hack' ? And are you still trusting them?

blunte2• 9 years ago

Some of these issues do seem concerning, but most wouldn't be profitable unless every miner was doing it (because the impact on one of these malicious behaviors will be felt in a later block).

Unless you're lucky enough to mine two blocks in a row, I don't see how you can gain directly from malicious transaction reordering. You'll consume the first retrieve fee, but the second retrieve will be in a later block (which you probably won't mine).

I'm not saying this is ok, but I'm also not sure this particular situation is worth the effort to exercise.

Transaction insertion, however, sounds like it would be very effective for the case presented. On the other hand, how big a deal are "guessing game" dapps?

You can sum all this up by saying, "consolidation of mining power can be used to exploit the network at the cost of non-miners". But consolidation is a problem for reasons beyond just these examples.

Finally, if a network becomes so corrupt, people will move to a different cryptocurrency (which will lower the value of the corrupt network). Thus, the bad actors would be taking small short term gains at their own cost of long term survival (especially when considering sunk costs in hardware).

shadowfiend2• 9 years ago

Full disclosure: tech lead on Keep (the project whose blog this is posted to), and the post is by one of our advisors.

It might not be worth the effort when volume is low, but if you have a highly-used set of contracts susceptible to this, there will be a stronger incentive to take advantage of them. With high volume, if you do it only occasionally, you can gain an edge without necessarily revealing network corruption (unless someone is looking for it). Additionally, this kind of careful misbehavior can lead to consolidation---by allowing some clever miners to gain enough of an advantage to continually grow their operation.

Note also that only the most basic transaction reordering gains solely from transaction fees. Transaction insertion requires no further blocks, and forced errors can be used to subsidize miner transactions (rather than simply to gain later on). Lastly, censorship has more than economic advantages, depending on the underlying application.

If the whole network becomes corrupt, people will move; however, there's a lot of room between "enough malicious transactions to cause a problem" and "network is so corrupt people are leaving", particularly if a chain is popular. Indeed, if a chain is popular, "just leaving" is not necessarily an immediate option. The important thing is that, as a developer for a given chain, you want to make sure you're aware of these pitfalls (whichever ones apply to your chain---many will apply across many chains) so you can design around them. More than many platforms, building for public chains require adversarial thinking. Or perhaps better put, they should require adversarial thinking. It's easy to forget that when you're getting started.

This is even more true when you're building components that you intend others to build on, which is what we're doing. That's what motivates the interest we have on our team in these kinds of concerns. We feel they're important to share as development on public blockchains gains greater visibility, interest, and therefore new developers.

UncleEntity• 9 years ago

and forced errors can be used to subsidize miner transactions

Sure, you can error out a transaction but what gain is to be had over just being a 'rational actor' and collecting the transaction fee rather than giving your rivals a potential payday?

Unless they have an extremely high probability of mining the follow-on transactions this attack seems to have a very low (or even negative) benefit.

Though I would posit that if this attack were ever consistently profitable the system would have a much bigger problem to deal with.

prestwich3• 9 years ago

Hi, author here. Look for part two for examples of how these attacks can siphon value from deployed contracts :)

moon_of_moon• 9 years ago

Just a miner inconvenience.

runeks• 9 years ago

Again, let’s design a simple smart contract. This time Alice wants to play a guessing game. Alice puts 5 Ether in her contract. That ETH goes to the person that guesses closest to the number she’s thinking of. Alice calls commit with the hash of the number, so she can’t change her mind. Anyone else can call guess to submit a guess. After 2 blocks Alice calls reveal to tell everyone what the number is.

This scheme is not unsafe because of miners. Transactions are public. As soon as Alice’s “reveal” message is published to the network, everyone can submit guesses using the revealed number. And miners are incentivized to include whichever transaction pays the highest fee, which means the transaction fee of the guessing transactions published after the “reveal” transaction will converge with the prize sum.

Alice’s commit transaction needs to specify some block height after which further guesses are ignored, and then publish the “reveal” message some (safe) number of blocks after this.

infogulch• 9 years ago

In other words, blockchain programming isn't trivial, and you have to translate your intentions into the contract with blockchain concepts in mind.

andybak3• 9 years ago

blockchain programming isn't trivial

This surely is a very bad thing. I'm not saying programming smart contracts should be trivial. Or maybe I am.

I guess the thing is - for Ethereum to have any chance of surviving it needs to be simple to write simple contracts. Easy things should be easy and hard things should be possible. And footguns should be removed from the language...

michaelchisari• 9 years ago

blockchain programming isn't trivial

This is an understatement, and belies the more appropriate: blockchain programming is dangerous.

Proceed with extreme caution.

shadowfiend2• 9 years ago

Full disclosure: tech lead on Keep (the project whose blog this is posted to), and the post is by one of our advisors.

You're right that this particular example has other downsides. The goal was to present the simplest examples of some attacks and issues that are easy to miss when doing blockchain programming. As I mentioned in another comment (https://news.ycombinator.com/item?id=16144892), the important thing is that, as a developer for a given chain, you need to be aware of the pitfalls of your chain (keeping in mind some apply across chains) so you can design around them. That includes the pitfall you described---everything is public, and that introduces some careful decisions that need to be made when building smart contracts. That one is pretty widely discussed; on the other hand, we hadn't seen any other content with a basic introduction to the pitfalls around miner misbehavior, so we felt James's post was super valuable.

I think a key piece of it is the last paragraph:

Miners aren’t your friends or enemies — they’re a force of nature in our consensus systems. Systems that fail to plan around this will eventually lose out to clever miners.

We've built many systems today that fail to take into account the dangers of ignoring security, and we're starting to pay the price. Public blockchain apps will need to be careful to have a decent understanding of the threats, especially since many of these threats have the potential to be even more directly tied to money than security issues in current systems. The more important (you consider) your system, the more important it is that your threat model include entities that are required for your system to function, like miners.

floatrock• 9 years ago

So in the same way a competent web programmer understands CSRF and XSS, a competent backend programmer understands SQL injection, and a competent node programmer understands concurrency vs. parallelism, there's a whole new set of paradigms (and interview questions!) that competent blockchain programmers will need to know.

The is-blockchain-hype-or-here-to-stay debate will unambiguously be settled if OWASP ever publishes a top-10 blockchain programming list.

prestwich3• 9 years ago

Hey, author here. Yeah, several of the example contracts are insecure in other ways. Or just plain bad ideas. I decided against providing implementations because I was worried people wouldn't understand that.

xucheng2• 9 years ago

Alice’s commit transaction needs to specify some block height after which further guesses are ignored, and then publish the “reveal” message some (safe) number of blocks after this.

I think this is unsafe as well. Noted that since everyone can verify the real answer, there is no point for Alice to reveal it. As a result, as soon as anyone submits the correct answer, the miners can cheat and replace the answer as their own.

After some degree of thinking, I find that it is quite difficult to design a secure smart contract such guessing game. I haven’t find a way can fulfill all following security properties: (a) the Alice has to pay for the first person who finds the correct answer; (b) that person can only collect reward after showing the the correct answer; and (c) the miner cannot cheat.

I wonder if anyone has a solution for the above problem. Also, if such solution exists, we can actually use it to implement the RSA challenge [1] in smart contract.

[1] https://en.wikipedia.org/wiki/RSA_Factoring_Challenge

nokcha• 9 years ago

One solution is to formulate the contract so that guessers submit a hash of (guess, nonce). The contract records each submission. A few blocks after the submission deadline, Alice reveals the correct answer. Then submitters of correct guesses send another message to the contract with their nonce. The contract gives the reward to the person who submitted a correct guess the earliest.

zaat2• 9 years ago

You can solve that with additional step: 1. Alice send the challenge. 2. You submit the answered, encrypted. 3. After you verify that your answer was included in a block, you post the private key you used for the encrypted answer. 4. Profit

comex• 9 years ago

If the commitment uses a salt, it won’t be possible for anyone to verify guesses before Alice publishes the reveal message (which would include the salt).

In any case, the blog post has Alice rewarding whoever comes closest, not whoever guesses the exact value. For a sufficiently large range of numbers (e.g. 128 bits), you wouldn’t really need a salt since the probability of anyone guessing the exact value would be negligible.

xg152• 9 years ago

And miners are incentivized to include whichever transaction pays the highest fee, which means the transaction fee of the guessing transactions published after the “reveal” transaction will converge with the prize sum.

Except the miner can simply include the transactions but add its own guess before all of them - so the miner would collect the fees and the guessing game prize.

abecedarius• 9 years ago

The LeastAuthority audit of Ethereum gas economics in 2015 brought up this issue of transaction reordering: https://github.com/LeastAuthority/ethereum-analyses/blob/mas...

(They also pointed the issue that led to the DAO hack and recommended "value reverts to the sender upon exception".)

ggregoire• 9 years ago

Miners are surely not gamers’ friends. All high end cards have been sold out for weeks. They are now completely overpriced ($1300 for a GTX 1080 Ti).

cornyNetHandle• 9 years ago

They are, on the second hand market.

mdip• 9 years ago

By that same token, they're not other miners' friends, either. I own three 1070s and a 1060 which I purchased primarily for mining[0] but also because other things I do benefit from the added compute capability. I purchased the first 1070 for less than $350 right after release. I can't find them for less than $400, now.

The funny thing about that is I'm funding my other needs for graphics cards[1] by mining. I wouldn't say I've "paid" $400 for any of them past the first one since all of the others have been funded with mining profits. And I probably wouldn't own three graphics cards were it not for mining.

At some point, I firmly believe, the bubble will pop on all of this and those cards will come back down to earth (I've been saying this for over 4 years, though, and have been wrong for at least that long). Until then, mining to buy video cards is always an option. :)

[0] Mining is kind of a secondary reason. The primary reason is that I wanted to learn CUDA and I know myself well enough to know that if I don't have a project in mind, I will never take the time to learn it, so I set about optimizing an existing CUDA mining implementation and set about learning it successfully.

[1] I play computer games pretty rarely, but I like to fuss around with modeling programs and having a few of these really speeds up rendering in programs that support IRAY. I'm using it for playing with ML code, as well, which wasn't enough of a project to get me interested in learning CUDA, but is enough to keep me interested now that I know the language a bit.

cookiecaper2• 9 years ago

Are people now moving on to nvidia cards for mining? I haven't followed closely for several years, but back in the day, it was all about AMD because nVidia's chips were much less efficient at this type of work.

If nvidia is now in demand for mining, are people going for that because AMD is nowhere to be found and they're just going for the next-best thing, or has nvidia gotten better at this?

dave72• 9 years ago

The latter. Less efficient, but in the current market still pennies on the dollar as far as nVidia efficiency goes.

scyclow• 9 years ago

It seems like a lot of these problems are due specifically to using proof of work. Do any of these problems go away with other consensus algorithms? I would at least expect that miners wouldn't have as much incentive to arbitrarily cause errors if they were using something like proof of stake.

Also, how easy is it to detect that miners are doing these things? If it's not terribly difficult, then maybe a federated system would iron out some of the wrinkles?

mhluongo7• 9 years ago

They do! But usually they get shifted elsewhere. While he was working on this post James and I discussed how PoS might yield stronger incentives to DoS rivals and get an advantage, since some of these other optimizations (attacks? Unclear) will be unavailable.

Edit: Regarding detection, of course- but I'm not sure detection lends itself to a general solution outside name-and-shame. Most of these are things developers should code defensively against.

Disclosure: lead at Keep, edited this piece

prestwich3• 9 years ago

Hello, author here. I haven't put a lot of thought into this yet, but my first guess is that this could become more of a problem with staking. Stakers still need to optimize, but all the easy ways are gone. Can't build better ASICs for staking.

Detection is hard. Like with selfish mining, it looks just like normal network operation in most cases. Most obvious mitigations don't work well either. E.g. we could try to establish canonical tx ordering in the tx pool. But then we would have to come to consensus about what the txpool is. Which is a bit of a chicken/egg problem.

cjbprime• 9 years ago

Nice article! Here's another type of failure with its solution:

* You want to register a domain name on the blockchain and associate it with your address, so you submit "register foo".

* The miner sees it, and inserts an earlier transaction registering foo to them instead.

Solution:

* You register the hash of foo, which registers the plaintext encoded by that hash, then wait until the transaction is accepted publicly and submit a second transaction that reveals to everyone the plaintext of the hash that you registered.

The miner could still try to guess at which name you're registering based on the hash (by having a long list of potential names to hash just in time), but I can't think of a way to do better than that. Anyone else?

bdr• 9 years ago

You register the hash of domain+seed. Second transaction reveals both.

SimonPStevens• 9 years ago

Couldn't someone else then simultaneously register the hash of the same domain with a different seed? Neither of you would know of the duplicate until you revealed your seeds.

theoh2• 9 years ago

This is similar to the rainbow table attack on password hashes. The defense against that is to use a (public) salt when computing the hash. Maybe something similar will work here, though I'm not clear about the details of your notion of "just in time" hashing. The salt just prevents precomputation of hashes.

fyi1183• 9 years ago

It would be better for the salt to be private (and revealed at the same time as the name), otherwise a miner could still try to guess at the name being reserved. Having a public salt only eliminates the possibility of precomputing many hashes, i.e. rainbow tables.

drtr• 9 years ago

Sure. Register encrypted domain name and a one-time public key. Next block, reveal private key.

CloudYeller• 9 years ago

Do these vulnerabilities affect BTC? Is there any unbiased source of security reports on all the various coins?

wk2jkhkjdfglsl2• 9 years ago

Not exactly because bitcoin only supports a few simple transaction types -- Pay to Public Key, Pay to Public Key Hash ('standard tx'), Pay to Script Hash, Pay to Public Key Witness Hash, Pay to Script Witness Hash.

These are only serial dependent -- ie: A pays B, B pays C. You cannot reorder and still remain valid.

The security of the standard tx is the strength of the public key hash function RIPEMD-160. The security of Pay to Script Hash is finding a valid SHA256 collision with OPCODES.

The witness variants are a new tx format that uses less space (aka segwit).

The attack is simply a Denial of service, an attacker can block a tx. So if A pays B was never included in a block, B could never pay C.

anigbrowl• 9 years ago

IT's capitalism in its purest form. The work done is work n the physical sense of production, but from a labor perspective it ends up as a constant rote of attrition and self negation - people gt interested in coins to make a quick buck and take it easy, but either drop or spend all their time, energy, and money racing for a slice of the pie while producing little of value - in this case, trust tokens which may or may not turn out to be valuable later. The rewards always go to people who were there early and had excess capital to spend on buying, or could mine easy pickings and then let someone else take over the grind.

Oddly the mining analogy reminds me most of Eve Online, which has a professionally tuned in-game economy and where you basically have a graphic representation of everything mentioned in the article, including the tedium and energy of mining, the endless technological arms race (designed to make you invest as much time as possible or buy credits to leapfrog other players), and pointless destruction of wealth - intra-player conflict is where most of the action and excitement is because the exploratory aspect of the game is only as interesting as it yields new technology that gets recycled back into the arms race.

Perhaps the solution is a medium of exchange that doesn't use absolute units, but is a function of your ability to pay.

rphlx• 9 years ago

a medium of exchange that doesn't use absolute units, but is a function of your ability to pay.

This is already implemented in many areas of modern life, especially by governments (Obamacare, progressive taxation, social security, etc), and it has a major negative side effect of incentivizing poverty: either real (by encouraging the young to work as little as possible) or faked (by encouraging those with accumulated wealth to conceal it as much as possible).

lsc• 9 years ago

yes, if we take away the "he who does not work, neither shall he eat" incentive[1] people will work less. Is that good or bad? depending on your ideology, it could be either one. Do you think that it's ethical to threaten the poorest with starvation to add a few points to our gdp?

My own personal view is that using starvation to incent work is acceptable only if society is unable to produce enough food for everyone; in that case, those few points to the GDP have real impact. I personally don't feel that it's okay to use starvation to incent work when that work largely produces luxuries, but that's just me, and everyone has an opinion on this one.

[1]Interestingly, historically this aphorism has been a leftist saying... that is, the rich should have to work, too. Leaving aside my controversial views of the bible, in more recent history, John Smith used it to this meaning in Jamestown, and then in the early 20th century, Lenin argued that it was a fundamental principle necessary for socialism to work. Both were talking about situations were people were starving (the early days of Jamestown and the early days of the Russian revolution, respectively) More recently, it's used as a rightest saying, arguing that the poor ought to work or starve, something that was the assumed truth in earlier ages.

anjc3• 9 years ago

The rewards go to the people who took on the most risk (i.e. the creators, and then the early investors). If Ether didn't have speculative value then the project would not have proceeded.

bfsg• 9 years ago

So many false assumptions in this post. As if only 1 miner is trying to mine a block. There is simply no way to know whether you or someone else is going to mine that specific block, it's totally random.

There are two ways to increase mining profitability: generate more revenue, or reduce expenses.

No. There are more ways. Mining the right coin at the right time and selling it at the right time for example.

Mining has a lot of common ground with investing in the stock market. It's not that simple.

ShabbosGoy• 9 years ago

Looks like the author of this piece is not aware that proof-of-work is antiquated and essentially obsolete.

There are way better methods to achieve distributed consensus, like Hashgraph or even proof-of-stake.

Edit: The critique that if the blockchain is slow, your Dapp will be slow is fallacious as well. You can mitigate that using side chains.

MrBingley• 9 years ago

Can someone explain to me how on earth Ethereum is still a thing? People have lost hundreds of millions of dollars in the Ethereum ecosystem, many due to basic flaws in the "Solidity" language. For example, last November $280 million was frozen in Parity wallets because function visibility defaults to external rather than internal (see the previous HN discussion here[0]). Just for fun, I was looking through the Security Considerations[1] in the Ethereum docs, and here are two so-called "minor details":

- In `for (var i = 0; i < arrayName.length; i++) { ... }`, the type of `i` will be `uint8`, because this is the smallest type that is required to hold the value `0`. If the array has more than 255 elements, the loop will not terminate.

- The `constant` keyword for functions is currently not enforced by the compiler. Furthermore, it is not enforced by the EVM, so a contract function that "claims" to be constant might still cause changes to the state.

WTF?! Trivial loops won't terminate to due (unchecked) integer overflow, and the `constant` keyword does nothing? It's a complete gong show. I'm not touching anything to do with this language with a 100 foot pool. Is the hype bubble just that big?

[0] https://news.ycombinator.com/item?id=14807779

[1] https://solidity.readthedocs.io/en/develop/security-consider...

Edit: Oops, it looks like I'm mixing up my multi-million dollar screw-ups. First in July $30 million was stolen due to the "public is default" debacle, and then the fix for that problem introduced another bug (the developers forget to call the `initWallet` function), which lead to the $280 million being frozen in November[2]. Holy crap.

[2] https://news.ycombinator.com/item?id=15642856

Bromskloss• 9 years ago

Does Ethereum's existence hinge on Solidity? Isn't Solidity just a language that one can compile to the lower-level language actually built into Ethereum?

masklinn• 9 years ago

Solidity is the official language, part of the ethereum project, and pretty much all you get when you look for how to develop eth contracts, unless you specifically exclude mentions of solidity. Then you get Ivy (prototype & for bitcoin not eth) and Pyramid Scheme.

So I'd say yeah, technically not but practically it is.

blunte2• 9 years ago

The promise of Ethereum was to be a global, decentralize, virtual computer. Without smart contracts, it's just another electronic value exchange platform.

ve552• 9 years ago

You could have other languages that compile code into EVM-executable opcodes, but Solidity is currently the language used by all major players in the Ethereum ecosystem for writing smart contracts. Although there's other options (or new options could be made), it's very unlikely that Solidity will be replaced by any of them any time soon.

mhluongo7• 9 years ago

Yep, anyone interested in taking a crack can write a language that compiles down to the Low-level Lisp-like Language (LLL) intermediate lang.

There are a couple projects working on it (eg Viper), though many seems to prefer starting a new blockchain.

Edit: s/Serpent/Viper/

52-6F-62• 9 years ago

Not explicitly. Currently, it's the most widest used language for interacting with the VM, but it's not the end development goal. I don't think the entire thing hinges on Solidity, though it's probably the most immediately accessible language. The hype driving the price up seems a bit premature, though.

There are a couple of other languages in development that might improve the ecosystem:

* Vyper https://github.com/ethereum/vyper

* Serpent https://github.com/ethereum/serpent

mannykannot2• 9 years ago

I think one can say that these issues of miner 'optimization' and some of the issues raised in the LeastAuthority audit [1] are architectural, rather than Solidity-specific, and which can only be addressed through defensive transaction design.

[1] https://github.com/LeastAuthority/ethereum-analyses/blob/mas...

twic• 9 years ago

Someone told me recently that there's an idea to replace EVM (the lower-level language actually built into Ethereum) with WASM. That would allow people to target it with a variety of existing programming languages, some of which are not clown shoes. If that's possible, it sounds sensible.

UncleMeat• 9 years ago

Even EVM has complex semantics surrounding critical features like time, dispatch, and exceptions. The whole ecosystem is amateur.

jancsika4• 9 years ago

Well, they start with an assumption that the halting problem is addressed simply by "running out of gas." I could easily see a dev assessing the infinite loop potential and glibly thinking, "well, that would just run out of gas, too."

That doesn't explain the lack of guarantee on "constant". What is the technical detail which prevents such a guarantee?

falsprofet• 9 years ago

I don't know, but constant as a function return value signature does not make much sense at all.

ve552• 9 years ago

Solidity has a lot of potential pitfalls that need to be avoided, just like similar languages. Some of these are due to poor or unintuitive language design, although a lot of improvements have been made over time. The wallet bug involving Parity's multisig wallets was due to an error that Parity made, even if it's an error that may have been easy to make, it should have been caught in testing or code reviews due to how critical that library was. As far as the loop goes, you cannot have a loop that runs forever due to gas limits involved in transactions (a contract can only execute so many opcodes before it hits the gas limit and execution halts, with state reverted back), so it isn't a potential issue that it would never terminate. With that said Solidity still has some pitfalls that should be fixed, and many of them already have been fixed. It's not perfect, but it's quite usable compared to other smart contract systems, few of which are even as developed.

Most of the largest headlines involving loss of funds in the Ethereum network have been due to programmer or user error. Keep in mind that Ethereum is still in its "experimental" phase - it isn't "supposed" to have billions of dollars put into it just yet, but the market doesn't care about this as long as the prices are going up. Ethereum could be much worse than it is, but that wouldn't mean its value would go to zero, or even do down. Plenty of top coins by market capitalization have been orders of magnitude worse, or just outright scams. Remember "The market can stay irrational for longer than you can remain solvent".

It's still a very new area of technology despite the amount of money that pours into it. There's innovation, but it can be difficult to see it in the midst of the hype.

mtgx• 9 years ago

Most of the largest headlines involving loss of funds in the Ethereum network have been due to programmer or user error.

Well, that's reassuring. Should we expect that there will be no more programmer errors in the future on the Ethereum network then? Isn't Ethereum's job to minimize those errors?

jstarks• 9 years ago

It’s well established that humans will make programming errors, and that good language design can reduce the rate of such errors (and eliminate certain classes of errors altogether). I’m surprised you are willing to place so much blame on Solidity’s users for their mistakes when these mistakes would have be avoided with simple improvements to the language design.

Jasper_• 9 years ago

Most of the largest headlines involving loss of funds in the Ethereum network have been due to programmer or user error.

What other classes of errors are there that Ethereum is successfully avoiding?

cookiecaper2• 9 years ago

The key difference between Solidity and other languages, of course, is that most people don't trust other languages so explicitly and irrevocably. Other code environments can be monitored for errors and those errors can be corrected, usually in ways that don't involve kissing all the money goodbye.

On something so absolute as Ethereum, I would expect them to use a very dumb language with as few complications and complexities as possible, and then to formally verify the crap out of it, and quickly make it the most consistent, predictable, and stable language on the planet (again, possible only with a very barebones language that does not have complex features). The fact that Ethereum has been around for so many years and this has not happened indicates that it's not a serious platform.

spookthesunset• 9 years ago

Who cares about the language when the very premise of the project "code is law" was proven wrong. When the DAO was "hacked" by a "thief", rather than tell people "whelp, code is law and the code executed perfect" the mob (more accurately, those at the top of the etherium pyramid) decided to change history and roll back the blockchain.

Even the language designed to describe the "hack" was garbage. It wasn't a "hack", if code is law, all bugs are code and therefore part of law. There was no "thief" that "stole" anything either. Code is law. Somebody followed the contract down to the letter and made a trade to their benefited. Code is law.

If the central tenant of "code is law" cannot even be held and real meatspace-based humans can modify history at will.... what value does ethereum add at all besides pissing away an unimaginable amount of energy turning non-renewable fossil fuels into heat?

If anybody can modify history.... just use AWS. It's cheaper.

epistasis3• 9 years ago

IMHO, "code is law" is a silly thing to aim for, and by ignoring that saying for the DAO incident proves that Ethereum is more valuable than it would be otherwise.

The "code is law" is just hype about how amazing and new and unprecedented this thing is, but it's a truly bad idea. The reversibility of bugs is a good thing. In human law, there are exceptions, and appeals, etc. Aiming for a completely mechanical system is the type of unnuanced thinking that leads me to be extremely skeptical of the entire cryptocurrency community, and in particular made me think that Ethereum was a total joke run by unserious people.

Computer tools must adapt to human nature, not the other way around. Ethereum's hype train ignored that. Such temporary hype trains can help get the train moving, but it's always important to separate the hype and marketing from the reality. Especially in everything from post 2000 in the Silicon Valley, hype and marketing are what drives success much more than product itself. We need to remember to not get high on our own supply, and not believe the bullshit that gets peddled in order to drive platform adoption.

paulmd3• 9 years ago

The problem with the "code is law" principle is that it's also the version of history where a single attacker controls 15% of all Eth in existence. I think most participants probably would agree with that principle in general, but the practicalities outweighed principle in this situation.

(the fact that the creator of Ethereum was heavily invested in the DAO doubtless played a role as well... it's different when it's your money that got stolen, and he had the power to do something about it.)

Still though, people don't understand that the legal system is a feature, not a bug. A neutral arbiter that can judge the spirit of the contract and come to a decision that resolves the matter fairly for everybody... that way you don't need to guarantee bug-free code forever.

There was a post here a while back that made the interesting point that essentially everything cryptocurrency attempts to do is anti-user and the problems they claim to solve would actually be viewed as features by most people. For example, no chargebacks! But chargebacks are a good thing, if the good turns out to be significantly not as described then you can get your money back. Or - immutable history! But it's actually quite nice when the bank can remove fraudulent charges when my wallet gets stolen, I quite like having that recourse.

3% merchant fees for Visa don't seem so bad compared to the DAO hack and Solidity and all that other shit.

elmar• 9 years ago

"We have no idea what we are doing!" Karl Floersch - Ethereum Researcher

https://youtu.be/ycF0WFHY5kc?t=991

anonacct37• 9 years ago

You seem to think terrible design is a blocker to adoption.

Are you acquainted with Javascript or windows?

Mbioguy• 9 years ago

Sounds like 2 things are getting confused.

Think of Ethereum as a very slow decentralized computer. People make mistakes building applications all the time, but this doesn't necessarily mean the underlying language, or for a better comparison, the compiler is at fault. Problems with the underlying language can cause problems with applications, obviously. Programmer error =/= language/compiler error, while both can occur.

People have been talking about the Parity hack like it's Ethereum's fault. Imo that's as absurd as blaming C for your program crashing to your coding error.

Your post, while you are confusing two types of errors, isn't completely off. Solidity does need improving. Any language has to pick tradeoffs, and evolves over time as it becomes apparent what the system's needs are. But Ethereum and Solidity aren't to blame for most of the ETH-based apps that rushed to market without an appropriate level of QA and review, cut corners, made mistakes, and caused catastrophic problems for their users like the Parity bug... this should be ringing bells, folks.

keymone10• 9 years ago

I’m not sure who is more clueless - people that trust JavaScripty shit-language to manage their finances or people that built a cryptocurrency around javascripty shit-language.

But I definitely assign some guilt and responsibility for all the money lost in solidity contracts to creators of ethereum.

kevingadd5• 9 years ago

Ethereum and Solidity absolutely bear some of the blame for bad software if the software is only bad because the tooling is garbage. You can't just kick the can down the road, runtime and compiler authors have a responsibility to actually do a good job. PHP cost people tons of time and money in the bad old days and again, you can't just blame people for using PHP. You have to fix it.

At the end of the day of course, the biggest error was on the part of the app developer, #1 because they used a bad platform, #2 because they didn't QA enough to compensate for the platform being bad.

But it still comes down to the fact that Ethereum and Solidity are low quality and the low quality results in more bugs and lost money than we'd see otherwise. It's just like the bad old days of Windows XP (and the modern days of Cryptolockers) except now money is directly vanishing into the ether because bad software is controlling it.

paulmd3• 9 years ago

The problem is that it's virtually impossible to write a "correct" program in Solidity, there are just too many pitfalls that are literally trivial to run into.

https://news.ycombinator.com/item?id=14810008

https://news.ycombinator.com/item?id=14691212

It turns out that having a language designed by a 17-year-old who knows some Javascript might not be the best idea in the world, who would have thought?

The language needs to be thrown away and a more proper one implemented, plain and simple. Solidity is unfit for purpose.

jovial_cavalier• 9 years ago

Right, so you're saying if they decided to use Brainfuck instead, then it would be just as silly to complain? After all, it's not an issue with the language, which is perfectly functional, it's just that you're too stupid to write something in Brainfuck that actually works.

The point is that the designers of Ethereum shouldn't have been so short-sighted as to choose the hipster JS offshoot of the week to build their massive multi-million dollar distributed computing system on top of.

Iv3• 9 years ago

Maybe because that is so fat the largest functioning cryptocurrency based on proof of stake instead of proof of work, and that bitcoin proved that energywise, a global cryptocurrency would not be sustainable?

keymone10• 9 years ago

Ethereum is not based on proof of stake.

Bitcoin proved that global cryptocurrency is absolutely sustainable, it just can’t be cheap.

paulmd3• 9 years ago

Can someone explain to me how on earth Ethereum is still a thing?

Network effect and name recognition, the same reasons that Bitcoin hasn't been supplanted by Monero or Zcash or any of the other dozens of coins that do virtually everything better than Bitcoin.

The really interesting thing is that the original plan for Bitcoin included many of the same programmable-money features as Ethereum. The instructions are still in the bytecode but I believe they were disabled in one of the patches, except for a handful of instructions that implement the basic "send money from A to B" type functionality.

My impression is these were supposed to be enabled/used at some future date, but this is just one more thing that's gotten bogged down by the infighting and politics of the project. Much like blocksize - 1 MB was just a number picked to avoid transaction spamming blowing things up in the early days, not a divinely inspired number intended to be used for all time. But the project is so stagnant and calified that they can't handle even the smallest day-to-day tasks like this. God forbid we change one of Satoshi's sacred constants.

Zpalmtree2• 9 years ago

While monero is very cool, it has the same scalibility issues as bitcoin i believe, but to a worse extent as the transactions are much larger due to how the ring signatures work. I know they're working on this but it's not a straight upgrade, and last time I checked monero fees were quite high compared to other alt-coins with similar use.

woah• 9 years ago

Why are you wasting people’s time in the comments on a technical article with your strident political opinions? This comment has nothing to do with the article.

bsenftner2• 9 years ago

Can any explain how the economics of mining does not promote the creation of a miner monopoly, aka a "miner Amazon". Once a single entity controls mining, Game Over: the economy is owned.

gt_• 9 years ago

Anyone with compatible equipment can mine on the network; no permission needed.

solatic• 9 years ago

Anyone who owns 99% of compute capacity can distribute a patch to the "distributed" network forbidding blocks mined by "unauthorized" or "unofficial" clients, and since that person's 99% of the compute power constitutes a majority, newcomers are effectively locked out.

Blockchain's dependency on distributed computation remaining democratic with a diverse range of self-interests is axiomatic to the model.

tinco• 9 years ago

You are answering your own question. Suppose someone would invest billions in obtaining a mining rig that single handedly achieves 51% of the mining power of the network, then he effectively kills that network, and makes his investment worthless.

There's a reason the valuations of Bitcoin and Ether waiver every time it seems a pool is coming close to 51% mining power, it's because everyone is scared of what happens when that happens.

In the real world, I think miners approaching 51% of mining power is an accidental and temporary thing. It means that the coin is overvalued, and investors are over investing in mining operations. As the article states, the amount of profit these operations turn really isn't that big. They're operating on thin margins, and operations going bankrupt is not unheard of.

There's simply no reason to go and "own" the network. Best case, you'll turn a loss, worst case, you destroy the network and lose your entire investment.

plantsbeans• 9 years ago

If you can keep your majority a secret, you can avoid the devaluing scenarios. The trick is to use the majority only when you need to, and to avoid detection.

bsenftner2• 9 years ago

Suppose someone would invest billions in obtaining a mining rig that single handedly achieves 20%, or 30% or whatever% of the mining power of the network, then they effectively use that advantage to achieve manipulation of the network or manipulation of the economy via their monopoly/large-entity level oversight of the economy. As you point out, there is no incentive to kill the network, but quite a bit of incentive to manipulate the network. Via modern corporate shells, no doubt people/groups are already trying to achieve this, they do in any market.

stordoff• 9 years ago

Isn't that incentive enough for any entity to deliberately stay below the threshold? Once they cross it, trust in the network, and thus price, plummets. That's reason enough for most to avoid getting that big.

matthewbauer• 9 years ago

How would you know though? IP addresses can be concealed by VPNs.

pmontra• 9 years ago

Aren't all of those scenarios covered by fraud laws? Obviously one should be able to provide evidence that an actual miner willingly reordered transactions to get paid twice. I don't know if this is possible (gathering the evidence.)

Tepix2• 9 years ago

Miners are not required to put anything into a block in any particular order. If you don't like what they are doing, stop paying them.

pbhjpbhj3• 9 years ago

"In this way, Proof of Work forces miners to constantly re-invest revenue." (the OP) //

Classic capitalist view. It's not that miners are forced to reinvest, if all miners were satisfied with the status quo then it could continue and each miner would get the same returns - depending on the structure of the system, greater demand could even drive hash value up.

But miners aren't satisfied, they want more, and new miners want a go at picking from the money tree. So the available pickings get higher up (require more resource expenditure). In theory, and often practically, it drives optimisation. Ultimately the return should be so low as to match safe investment returns.

It seems it should be possibly to design a system such the the coin holders can effectively own the means of hash production, which would keep value in the system.

andybak3• 9 years ago

Classic capitalist view

I would consider myself center-left and I think you're confusing "capitalism" with "realism".

Any political system that requires altruism towards strangers is doomed. Altruism grows out of community - and requires consequences for "bad" behaviour to some degree. Tragedy of the Commons and all that.

deft• 9 years ago

Capitalism demands constant growth. His usage fits perfectly. Center-left means you are a capitalism supporter and makes no difference. Claiming the capitalist mode of production is "realism" is really you trying to say capitalism is natural.

robert_davidson3• 9 years ago

I phrase this as "incentive alignment". Every stable system aligns incentives with its continuation.

DINKDINK• 9 years ago

Ethereum is a decentralized platform that runs smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference.

Except that ethereum is lying when they say this. The DAO contract was nullified and censored. The Ethereum Foundation and the DAO team were bailed out and had preferential treatment.

anjc3• 9 years ago

And how was the contract nullified exactly?

robert_davidson3• 9 years ago

It was replaced with a new contract via a hard fork. Doing so was the right move, by far, but purists loathe the move.

rhaps0dy• 9 years ago

The title of the piece is "Miners aren't your friends", implying that the interests of miners and the reader differ. However, the title of the HN submission is "Miners aren't friends", which implies that the interests of two separate miners diverge.

We should probably change the title to match the original one.

scott_karana• 9 years ago

Agreed, I was frustrated at that too.

JonasJSchreiber• 9 years ago

As someone who has a couple rigs mining 24/7 I would say he’s looking at the profitability of mining wrong. Personally I don't reinvest my mining profits in more mining equipment. There's a hard cap on how much amperage can be delivered to my house, and I have no interest in interfering with my daily appliances.

As far as when does it becomes profitable to play games with consensus? Never. Most miners mine using pools like suprnova, ethermine, and nanopool. I don't have control over whether we are appropriately confirming transactions or not, but it would be pretty unwise for my pool to start violating consensus.

caf2• 9 years ago

Another instance of this is if you managed to build a business around a particularly profitable contract or set of contracts, the nature of which requires you to regularly post maintenance transactions of some sort.

If you get big enough and profitable enough, the miners will have an incentive to specifically refuse to include your maintenance transactions unless you include a large transaction fee - in other words, market segmentation for transactions.

thisisit• 9 years ago

Miners have proven to be unreliable. F2pool has been accused of manipulating Status ICO:

https://steemit.com/ethereum/@dhumphrey/f2pool-manipulates-u...

Miners Aren’t Friends

Related Stories