Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large Hashrate Pools Accidental DDOS! #172

Closed
DominiLux opened this issue Nov 7, 2016 · 15 comments
Closed

Large Hashrate Pools Accidental DDOS! #172

DominiLux opened this issue Nov 7, 2016 · 15 comments

Comments

@DominiLux
Copy link

Proposal:
if two miners are working on the same block and one block has txns while the other block does not, then the miner with the included transactions receives the primary reward while the miner with no transactions receives the uncle reward. Otherwise, standard reward rules would apply.

Rational:
Pools with larger hash-rates have recently been using the built in feature to only process their nodes own transactions. While the network appears to be moving along smoothly, it becomes highly probable that these particular pools will find blocks faster than those who are bogged down trying to confirm transactions. This leads to an unintentional denial of service attack whereby it takes longer to get a given transaction included in the longest chain and propagated through the network.

This small change in the rewards system would discourage such activity and encourage honest mining thereby increasing the networks transaction capabilities. I have not run an algorithm through the block-chain, yet, but I theorize that only 1/3 of the network is actually processing transactions while the other 2/3 are ignoring them and only mining blocks with 0 txn affectively taking ether without contributing to the network. There are two major heavy hitter offenders which you can inspect blocks minned to get an idea of the scope of this problem

#1 Offender On The Entire ETH Network:
BW
#2 Offender:
f2pool

these two pools alone involved in this type of dishonest mining is causing a disruption in txn processing times. Therefore, a simple reward change that makes it uneconomical to exclusively mine empty blocks when their is a chance of an uncle inclusion would stop this activity and restore the network to it's full txn speed. The current proof of work implementation makes it possible to cheat the system using this technique whereby your not actually contributing the same amount of work as honest miners who are including transactions.

Comments, Suggestions?

@janx
Copy link
Member

janx commented Nov 7, 2016

What if the miner includes a minimum tx of his own to make the block not-empty?

@3esmit
Copy link
Contributor

3esmit commented Nov 7, 2016

I assume this will be fixed on PoS, where no miner would have interest in building empty blocks.

@simonjanin
Copy link

simonjanin commented Nov 7, 2016

@DominiLux : Totally agree on the problem. But, as @janx said, miners can simply include a very cheap tx to themselves to make the block non-empty. So this doesn't work.

@3esmit : this won't be fixed by PoS. Miners have an incentive in building empty blocks when the cost of verifying them and transmitting the corresponding txs is higher than the value of the txs fees (think of the risk of block orphanage introduced by the network latency).

@3esmit
Copy link
Contributor

3esmit commented Nov 7, 2016

@simonjanin But in PoS a list of miners will be selected by RANDAO and the first of the list will be able to produce the block, miner will have a considerable time to calculate the tx until the next could produce it too, and the computation tx will be paid more than the resources consumption. So why not include transactions if it is profitable?

@simonjanin
Copy link

simonjanin commented Nov 7, 2016

@3esmit: Absolutely agree. I'm not saying that PoS cannot lead to improvements, and it certainly could.
Let's assume that the blocktime is 4 seconds, then this is the maximum amount of time a validator will have to receive the tx, compute/verify it, include it in the block, then broadcast it.
To be fair, the time for a validator slot to expire should be around 15 seconds which indeed reduces the incentive not to include some transactions.
But if we take, for example, a Chinese validator, then it may still be rational for him not to include some txs, because of latency. And this gets worse as the blocktime gets pushed down.

It's simply a matter of economics, but we've yet to prove this whole system is incentive compatible. My point was that it cannot be "fixed" with PoS, although I agree with you that it should improve the situation a good deal.

@DominiLux
Copy link
Author

@janx @3esmit @simonjanin @fjl @caktux I agree with all of you, this is not a full solution but it's intent was to present the problem with the beginning of a solution for debate until Proof Of Steak is ready. However, know one knows when this will be ready. It takes a lot of time, energy, and testing to develop a protocol change such as this. A lot of other issues have to be resolved before Proof Of Steak can even be implemented. Therefore, I ask everyone to provide a viable solution to the problem i've presented or additional rules to add upon the solution i've presented. For example: A simple rule on a protocol level that a miner is not allowed to process their own transactions and these must be forwarded on to other nodes and implementing the rule I initially mentioned would go a long way in correcting the Proof Of Work system while the Proof Of Steak system is being developed. This is a serious issue that appears to be going on across the majority of crypto economics. As the Ethereum community, we are the leaders on the forfront of blockchain development and change, so we must come up with a viable solution to be adopted to correct this logic error in reward rules which essentially allow cheating and unfair gain by those who are violating simple ethical principles for the sake of profit. However, since a blockchain is meant to be a trust-less system it is the protocols job and the responsibility of it's development team to correct such errors in logic. It's very much known that bitcoin is a centralized blockchain now controlled by a small group of miners. These same miners used similar techniques to centralized the bitcoin blockchain which was meant to be decentralized. I'm waiting on the day they "decide" to change the rules themselves and increase the finite minable limits imposed in the initial white paper. Ethereum is a bleeding edge blockchain so we have to set the example for a correction in the proof of work algorythm. I refuse to result to unethical mining for profit and will continue to process all transactions but I must say that as long as this remains unfixed, the larger groups who are practicing unethical mining will bleed honest miners dry with their 3 second block times verses our 43 second block times. The difficulty algorithm currently penalizes honest miners and rewards dishonest mining by the avoidance of transaction processing. This needs to be fixed in proof of work and the principles can then be moved to proof of steak. As much as I don't want to I am going to be writing up a long in depth article regarding the problem and publishing it on every major news site possible. Noise will be made and this issue will be fixed even if it means that someone has to create a competing chain with this correction in logic to provide fairness within the system.

To all honest members of this community; developers and miners alike; I solute you. To the dishonest, we will write code and implement systems to stop you. Ethereum is a great community and i'[m glad to be an HONEST member of it.

In closing if a proper fix to this problem is deployed in proof of work, when proof of steak comes out if the rules migrate over it will make the system even more resiliant because the miners in proof of steak stand to loose their entire account balance for violating to rules ;) so i'm all for it but we need to make some reward corrections to prevent cheating first and can test this on proof of work for viability on proof of steak.

@obscuren
Copy link
Contributor

obscuren commented Nov 7, 2016

Proof of Steak

@simonjanin
Copy link

simonjanin commented Nov 7, 2016

@DominiLux: It's unfortunately not possible to check whether miners are only including txs that send money to them. They could use a different address each time to circumvent any mechanism.

What you describe is a similar kind of problem to selfish mining. There is no way to completely disallow it, but we can make the protocol incentive-compatible; such that acting in your own interest is also in the best interest of the network.

Ultimately, maybe transactions fees should be higher (i.e the gas price)...

@redsquirrel
Copy link

@obscuren Yeah, I couldn't resist the steak.

@3esmit
Copy link
Contributor

3esmit commented Nov 7, 2016

@simonjanin
For me is a full solution, PoS fix this issue organically, unless there are miscalculations in the OP codes gas prices. This gas prices is proportion for resouces usage, and gas limit is how much nodes as willing to process each block.
While the current system PoW may have this weakness, as maybe could be more profitable to use all resources in hashing the difficulty puzze, in PoS with OP codes correctly proportional and transactions willing to pay a fair value of gas, why someone will prefer to win less profit? The block is just waiting to be created and you have plenty time, resouces and incentive to add the transacitons.

Imagine most miners are doing this because they want to harm the network, the transaction queue would be bigger, so people willing a transaction to be included fast will pay higher values in transaction, this will make incentive to run a node and stake ETH as validator, so market would self regulate it. And by finality concept that Casper implements the nodes don't even need to download the full blockchain to become validators.

There is no need to worry about this in PoS. To understand better watch this presentation by Vitalik Buterin, explaining PoS, security and scalability. https://ethereumfoundation.org/devcon/?session=14-the-mauve-revolution

I read the slides and watched it twice, now I'm pretty confident of ethereum PoS security and scalability.

@DominiLux
there is not much pending transactions, ethereum is not used that much yet, but still the second biggest blockchain and we are fine with those miners mining empty blocks. https://etherscan.io/txsPending
They may imagine is more profitable this way, or they are just trying to harm the network making more slow to get included transactions, but PoW will be soon replaced by Casper PoS and that would be not a threat to ethereum anymore, just to ethereum classic, bitcoin and others PoW blockchians.
The only solution for this problem in PoW relays on the people making transactions, they can make very high gas priced transactions so it would be extremly rewarding to include their transactions and so more people will mine.

@simonjanin @DominiLux
I think you guys are overthinking a small issue that will not even be an issue in future. Just to remember there is a difficulty bomb coded in ethash PoW, and PoW seems to stay really safe until this makes us change to PoS, so don't worry about this folks, relax yourself and enjoy the ride to the moon!

@3esmit
Copy link
Contributor

3esmit commented Nov 7, 2016

By the way we could make an announcement on reddit and other social media to miners move out those pools and go to pools that include transactions. What you think guys? Maybe there is the better place to discuss this.

@vbuterin
Copy link
Contributor

vbuterin commented Nov 8, 2016

Jan's point is decisive here. You can't explicitly incentivize transaction inclusion without creating incentives to make fake transactions (at least given current protocol economics; when you have mandatory burned fees things change a bit...)

@DominiLux
Copy link
Author

My primary concern with Ethereum is not monetary gain. I want to see it perfected because I think most of us in here share a common vision. I truly look forward to PoS and will continue to run dedicated bare metal nodes on PoS after mining is no longer possible. At that point I plan to transition over to development of some very interesting decentralized applications. I would begin this development now but given the unknown variables of change between now and proof of steak it makes more since to plan the logic and create the pseudo code for my concepts at this point. Then develop them when the network is fully ready. As for our core developers, I love the hard work you put into this project. If it realizes it's full potential as a true torren complete computer the founders are sure to win a Nobel prize. This project has the potential to completely change the way we communicate. If the ethereum foundation did a public IPO right now(Not ICO) i would buy shares up as quickly as possible because it has advanced the concepts of the decentralized transaction ledger to the future way that we compute. As we strive to come up with new transistor technologies from quantum transistors to photon transistors Ethereum is our next step in technological development to bypass the breakdown of moores law. Most people do not realize how important this technology development is because to continue research in quantum computing and (more probable) photon computing we need more computer power. But since moores law has reached the point of break down in current technologies this gives mankind the tools needed for higher computational capabilities which are necessary to further research in other transistor technologies. I believe once the system is fully ready it's usage in scientific research through shared computing power will be adopter rapidly.

Thank you all for your comments and feedback regarding my concerns.

@DominiLux
Copy link
Author

@redsquirrel I just noticed your steak joke... Now I desire to cook myself one, medium rare.

@DominiLux
Copy link
Author

Closing issue as already taken into consideration with future proof of "stake" update and difficulty bomb.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants