Are there any misbehaving miners?

Question

Many of the discussions I read about security relate to how miners can manipulate this or that aspect of the way a transaction gets processed, such as whether or not it's included, what it's timestamp will be, etc. But I wonder if there is any solid information on how many miners are out there trying to do these things? Is there a statistic out there (or can there even be one) that says x% of miners are behaving, while y% are trying to cheat? Is it really something that Solidity programmers need to concern themselves with?

I think so. If there was a time-locked contract that could only release funds after x number of years, I could set my mining node's time after the release time, continue to call the contract, which would normally throw on other miners, and just wait until my farm hit a block. There would be a gas cost for the attack inversely proportional to the hashrate of my farm. — o0ragman0o, Dec 28 '16 at 04:40
The question is not so much "can it happen" as "is it happening" and if it is, can we know about it? But, thanks for the comment. — Thomas Jay Rush, Dec 28 '16 at 04:43
That wouldn't work unless you had 51%, or someone was prepared to give you something for funds with a single confirmation. Your block would swiftly be orphaned: Miners would either reject it outright or try to build on it, resulting in an invalid block, because the timestamp went backwards between your lying block and their honest block. — Edmund Edgar, Dec 28 '16 at 04:50
@Edmund I don't think block timestamp is strongly validated for the reason that nodes can't be guaranteed to have correct time across the network. — o0ragman0o, Dec 28 '16 at 06:21
@ThomasJayRush, I can't find the thread (on forum.ethereum.org) but there was someone who wrote a contract on Frontier to lock away a large amount of ether for 10 years. This kind of attack was discussed and he withdrew it in such a way. — o0ragman0o, Dec 28 '16 at 06:47
@o0ragman0o Block timestamp not going backwards between blocks absolutely is a protocol rule. See more on this here: http://ethereum.stackexchange.com/questions/413/can-a-contract-safely-rely-on-block-timestamp — Edmund Edgar, Dec 28 '16 at 07:08
@EdmundEdgar, Ok thanks, but what constitutes 'too far in the future'? Seconds/ minutes hours? The other constraint mentioned,block time cannot be stamped with an earlier time than its parent, would mean that a node with time maximally advanced could force following blocks to invalidate until a successful node's time had caught up. — o0ragman0o, Dec 28 '16 at 07:32
It doesn't matter what constitutes "too far in the future". Like I said earlier the network can't build a successful chain on top of it until it actual time reaches its stated time. While it's waiting it'll get orphaned. — Edmund Edgar, Dec 28 '16 at 09:49

score 2 · Answer 1 · answered Dec 28 '16 at 04:57

2

Is there a statistic out there (or can there even be one) that says x% of miners are behaving, while y% are trying to cheat?

There can't be one, because the proportion that try to cheat depends on the incentive you create for them to cheat. Even if all the current miners are honest and incorruptible at any price, there are a positive number of greedy, dishonest people in the world, so if you create a big enough incentive for cheating those people will take up mining.

answered Dec 28 '16 at 04:57

Edmund Edgar

16,897
1
29
58

I'm not sure this answers the question. I totally understand that if the incentive is big enough, people will try to cheat. I'm trying to understand if there is any way to tell if people are currently cheating. And if so, what would that look like? – Thomas Jay Rush Dec 28 '16 at 11:12

score 2 · Accepted Answer · edited Apr 13 '17 at 13:01

You ended by asking if this is something DAPP developers need to be concerned with. I would say yes, some of it, to a point.

It's important to understand the degree of precision that exists, and the uncertainty that exists. There's more to be aware of than the delays caused by mining.

For example, the chain doesn't attempt to resolve the exact time of transactions; only the order they emerged on the blockchain. The block timestamp is unambiguous but it isn't especially accurate. Here's a discussion about how it could be off by up to 14 minutes: How would a miner cope with a huge block time?. They also talk about how incentives urge miners to be more accurate than that.

If you keep the uncertainty in mind, you will hopefully avoid designing with hidden assumptions that can lead to trouble in an edge case.

For completeness, I don't think it's possible to know how many miners (human or machine) would like to find a way to distort the Ethereum blockchain. I think we can safely say none have been successful to date.

Are there any misbehaving miners?

2 Answers2