miningmining-pools
What would be the safest way to combine my mining efforts across approximately 30 machines? Should I…
Ethereum uses a proof of work algorithm called Ethash which like Bitcoin's proof of work uses a difficulty number to adjust how hard it is to find a block.
In pooled mining, members send a valid proof of work to the pool of the same type, but of lesser difficulty, so that it requires less time on average to generate.
When the pool get's a proof from a member with sufficient difficulty, they can submit it to the network as a valid block. When they get a proof of lower difficulty, they have proof of the member's hash rate and can validate that they are working on the same block as everyone else.
There where discussions of how to prevent this when Ethash was designed, but none where found and it was decided to go ahead anyway, under the assumption that most miners would prefer solo mining given the faster block time.
(Please edit me. I'm a community wiki)
geth machine--rpc without checking that only your GPU mining computers can access TCP port 8545 on your Ethereum node geth computergeth computer.geth instance.From blog.ethereum.org - Security Alert – cpp-ethereum keeps accounts unlocked:
Affected configurations: cpp-ethereum (eth, AlethZero, …) version 1.2.0 up to 1.2.5 (fixed in 1.2.6) Note: Neither “geth” nor “Mist” nor the “Ethereum Wallet” (unless explicitly used together with cpp-ethereum) are affected by this, they lock accounts correctly again.
Severity: High
Possible Attacks: Attackers can spend funds from previously used accounts if they have access to the local machine or to an exposed json-rpc interface.
Details: Due to a bug in cpp-ethereum, accounts stay unlocked once their password has been entered until cpp-ethereum is closed. This includes accounts encrypted with the “master password” entered upon startup or any password entered through Mist. This means that an attacker can spend funds from the account as soon as they have access to the RPC interface. For that to happen, they either need access to the local filesystem or the exposed http-json-rpc interface (not the default setting). Using Mist in “Mist mode” (not the default setting) and navigating to a malicious website also provides that website access to the RPC interface.
Proposed temporary workaround: Restart eth after each transaction, do not expose the json-rpc interface via http and upgrade to version 1.2.6 as soon as binaries are released. A fix has already been merged to the develop branch.
Here are some steps to reduce the chances of getting your Ethereum wallet hacked.
For most Ethereum miners, you will be using geth to running the blockchain node and ethminer to perform the mining calculations.
If you are running only one geth instance and the ethminers on just one computer, restrict your RPC port to only serve on the local computer. The option --rpcaddr 127.0.0.1 (which is the default setting) will restrict your RPC communications to just that computer.
If you are running only one geth instance on one computer and ethminer on the same computer plus ethminer on other computers that will need to communicate with the one geth instance, you will have to use your computer's local network IP, for example --rpcaddr 192.168.1.123. In this case, it is best set up a firewall to restrict communications via RPC to geth to your mining rigs only.
geth Node ComputerIf you run Mist on your mining node, when you send a transaction with Mist, it will communicate via the IPC socket to instruct geth to unlock your account for 2 seconds.
If you have RPC turned on and this port is accessible from the Internet, scripts and bots will be able to send transactions on your geth node to snatch your coins in the short period of time that Mist unlocks your accounts, as happened to Patrick.
If you have RPC turned off and your mining computer has been compromised, any locally installed malware will be able to use the IPC socket to snatch your coins.
Don't run Mist on your mining computer. Use it on a separate secure computer instead.
$HOME/.ethereum/history File And Erase If NecessaryThe history of the commands you type into geth ... console is stored in $HOME/.ethereum/history. The following shows what I have just typed into the console:
> eth.mining
true
> personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
Decryption failed: MAC mismatch
at InvalidResponse (<anonymous>:-81662:-62)
at send (<anonymous>:-156322:-62)
at unlockAccount (<anonymous>:-133322:-62)
at <anonymous>:1:1
And here are the last two lines of my $HOME/.ethereum/history file:
eth.mining
personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
Check the contents of your history file using the command:
user@Kumquat:~$ grep unlock $HOME/.ethereum/history
personal.unlockAccount(eth.accounts[0], "invalidpassword", 2)
If you have ever used the command personal.unlockAccount(...), erase your history file:
rm $HOME/.ethereum/history
By default the directory in which your history file is located is only readable by your own user. But if your account is compromised, your password is in your history file:
user@Kumquat:~$ ls -al | grep .ethereum
drwx------ 9 user user 4096 May 14 00:28 .ethereum
Your mining computer is continually communication with other programs on the Internet and is at a higher-than-usual risk of getting compromised.
Hackers can easily find Ethereum nodes on the Internet and your computer may be targeted. Move your mining rewards to a more secure Ethereum account to reduce the size of your losses if you do get hacked.
Run the server version of Ubuntu Linux if possible. It is a little bit harder to install, especially the GPU drivers, but you have a lower chance of getting hacked as fewer services run in this version compared to the desktop version.
Ubuntu Desktop has many more bits of software running continually with exposed ports. If you do have to use Ubuntu desktop, turn off unnecessary services, don't install untrusted software. You may want to use the privacy settings to reduce any leakage of information:
/etc/default/appport. Set enabled=0Macs and Windows continually phone home and very likely have backdoors for Apple and Microsoft respectively. Even if Apple and Microsoft have little incentive to expose themselves by utilising the backdoors, the continuous chatter makes it hard to detect abnormal communications between your server and other computers.
geth instance, only allow communications on the RPC port from your mining computers.root (Or User With Administrator Privileges) To Run Your MinersIf your Internet facing programs (geth) has a vulnerability, a hacker can cause more damage if the program is running with administrator privileges.
Only the port 30303 for TCP and UDP traffic should be forwarded by your modem or firewall to your geth node computer. Port 8545 (or whatever you configured for your RPC port) should NOT be forwarded to your geth node computer.
My firewall rules are for my 2 mining rigs (.120 has the geth instance, .121 is just a GPU miner, .111.* is my DMZ):
* Allow Internet to DMZ geth machine TCP 30303
Protocol TCP, Source Any, Destination 192.168.111.120:30303
* Allow Internet to DMZ geth machine UDP 30303
Protocol UDP, Source Any, Destination 192.168.111.120:30303
* Allow Ethereum RPC 8545 traffic from GPU miner to geth machine
Protocol TCP, Source 192.168.111.121, Destination 192.168.111.120:8545
* Allow SSH traffic to mining rigs
Protocol TCP, Source 192.168.1.*, Destination 192.168.111.*:22
* Block everything else
Protocol *, Source Any, Destination 192.168.111.*:*
Use a service like GRC to probe for the open ports on your Internet connection. Click on grc.com, click on Shields UP!!, then click on ShieldsUP! again. Read the text and click Proceed.
On the web page shown below, I've typed in ports 8545, 30303 and clicked User Specified Custom Port Probe:
The probe results are shown below - Port 8545 (geth RPC) is not open to the Internet while port 30303 (Ethereum P2P port) is:
It's probably a good idea to test All Service Ports (Ports 0 to 1055) at the same time to confirm which ports you have open. The following results show that I only have port 443 (HTTPS) open:
Don't open up your RPC port 8545 if you have GPU miners outside your network.
Your alternatives if you have GPU miners outside your network with your geth instance:
geth locally within each of your GPU miner's networks pointing to the same coinbase account if necessary; orether-pool component of open-ethereum-pool. You don't have to run the web frontend, the unlocking or the payout modules. Only safe instruction from/to the GPU miners to/from geth passes through the mining pool software. One advantage of running this software is that you get a better performance from the stratum mining proxy protocol. The ability to mine with a particular coinbase (payout address) is not contingent on the mining node having access to the coinbase's private keys; you can generate the address and private key on another machine and set the mining node's coinbase to the generated address. This reduces damage from a compromised node: past payouts cannot be stolen by merely compromising the node.
Best Answer
Here are several equally safe ways of combining the mining efforts:
In all cases, set up one or more private key-public key-account address combination on a safe, air-gapped machine (with proper precautions to prevent air-gap-bridging by malicious entities). This is the key to security in any case. Record the account address(es).
Now, you can set up an Ethereum node instance on each machine and have them mine to an address you generated. This will minimize latency, assuming the nodes are fast enough to handle Ethereum transactions efficiently, especially for a geographically distributed network of machines.
Alternately, if you have all the machines in the same location, you may prefer to set up your own pool. In this situation, you can concentrate some resources on the quality of the node (e.g., high performance disks, large amounts of RAM, fast CPU) to minimize processing latency and decrease your chances of getting an uncle. You can also set up redundancy/failover for your network and the node; this allows you to upgrade your Ethereum clients without any downtime whenever there's a fork or software update.
Alternately, if this is too much for you, you can select an existing pool. The latency between you and the pool has negligible effect on your efficiency. The inefficiencies come from other places. The first is pool fees. Then there's the fact that several pools don't pay for uncle blocks or transaction fees collected. Then you hope the operator isn't skimming off the top and that the node is maintained properly (mining on the right chain, not experiencing downtime, and properly secured).
Whether you mine to the same address on each node or not is your decision. This should have no effect on your safety.