0

i'm pretty new to this topic but like to learn how things are working. I got some general questions to the different miner-settings available. First of all i know about pool-mining and how to set it up for different pools and i also know about the fact that solo mining is not worth but as i said i like the technical things and try to set different things up to make it work. I'am using geth. Got it full synced and added the "--mine" command to enable the ability to mine. Complete command :

geth.exe --http --miner.etherbase 0x42f1DE45fe91d741C968C4C976E19d3e2224EC16 --ethash.cachedir "K:\Blockchain_Ether\Blockchain\geth\ethash/cache/" --ethash.dagdir "K:\Blockchain_Ether\Blockchain\geth\ethash/dag/" --datadir "K:\Blockchain_Ether\Blockchain" --keystore "K:\Blockchain_Ether\Blockchain\keystore" --syncmode "full" --mine

This works fine i guess because when i attach to the node i get a "sync=false"-state which occured when the currentblock hitted the highest block. Complete Command:

geth.exe attach ipc:\\.\pipe\geth.ipc

When succesfull attached:

eth.syncing

If i gonna proof my Accounts with the following command i got my Adress which is totaly fine:

eth.accounts

Proofed my balance with the following command which returns 0 which is also fine:

eth.getBalance("0x42f1DE45fe91d741C968C4C976E19d3e2224EC16")

I would say that the node is running good this way.

Here comes the part i'am unsure about.

There are a lot of incomming mining work-jobs as you can see on the following screenshot: Geth synced node

I started a mining-tool called "etherminer" with the following command:

ethminer.exe -U -P http://127.0.0.1:8545

This workes good as i think. I mean the mining-tool stays synced with all the jobs incomming from geth. I proofed it by comparing the sealhash. Following Screenshot of the working etherminer (from another timestamp so hash-values are not matching) etherminer running

I was thinking about using the t-rex miner but i'am not sure about the "correct" command. The command i tryed looked like it's working as well but it get's waaaaaaay less jobs then the etherminer. I started the t-rex miner with the following command:

"K:\MiningTools\t-rex-0.24.8-win\t-rex.exe" -a ethash -o stratum+http://127.0.0.1:8545 -u 0x42f1DE45fe91d741C968C4C976E19d3e2224EC16 --mt 3 --pl 80 --fan t:60 --lock-cclock 0 --cclock 100 --mclock 100

Following screenshots showes the running t-rex miner with less jobs: t-rex running

Now my questions... :)

  1. Geth is sending a lot of jobs. Like a lot of jobs between each complete block. Etherminer is recieving all these jobs and starting to mine on every single job? Is there a reward for every single job? Compared to t-rex miner it looks like this tool only get the "full-block-job" which results into less incomming jobs. Is this just a visual thing that t-rex is not showing the micro-things happening between the lines ot is it not working this way? How is the reward system on that different methods?

  2. I can start t-rex with different algorythms. In my case i used -a ethash, does -a etchash would work as well and i just can choose on which algorythm i got more hashrate?

  3. When i start the miner in geth with the following command on the attached console: miner.start(2) It should start the CPU-Mining-Function with 2 Threads. (I got an i7 8600k with 6 Threads), but my CPU is instantly raising to 100%. Why is this the case? And when i try to stop the miner with the command miner.stop it dont work. The CPU stays on 100%. This only can be solved by terminating the complete synced geth node and restarting it. On bot commands i get the return value NULL which should be fine. But something is not working properly i guess.

  4. Does one of my setups should work? So based on my informations, would it be possible to find a block theoretically (low chance i know)? Port 30303 is still closed it seemed to be not neccesary - hopefully i'm right? :)

Hopefully there are some people to help me:) I just like technical things and just want to make it work, understanding things. Any help even to understand the whole things more and more would be awesome!

Take care - stay healty !

1 Answer 1

0

How basically startum mining works

  1. Consider mining on geth over getwork (the rpc enabled one).
  2. Let's say a job has possible hash range of numbers from 1 to 100.
  3. Let the correct share be the hash of number 52.
  4. So when using ethminer, it starts to search from 1 to 100 for the hash (Not exactly in this manner, but consider as an example)
  5. So it took 10s to find 52 was the number for the hash

    Coming to the protocol which trex uses (stratum)
  • Startum protocol is the most used one's in mining pools This will help the pool to divide the above range of 1 to 100 for different miners
  1. So let A, B, C and D are the miners connected to the pool
  2. Pool divides the range to search for each miner
  3. Let the range
    • 1-25 for A
    • 26-50 for B
    • 51-75 for C
    • 76-100 for D
  4. For the above job, the correct number is within the range given to C
  5. So if it took 10s for ethmine to reach the number 52, per hashing time could be ~0.01s
  6. So here C would find the hash within ~0.03s
  • Which is way faster than the ethminer alone
  • And the block reward will be distributed to A, B C, and D with respect to their hashrate

That's about the T-Rex
So the solution is T-Rex should be able to communicate to your geth node via a stratum interface like this

T-Rex <--> Stratum <--> Geth Node



Which algorithm to choose

  • Ethereum blockchain uses ethash or Daggerhashimoto as the algorithm to calculate the hash of the blocks
  • So you cannot use a different algorithm to submit a hash for the block.That would be invalid
    • ETC will take Etchash
    • ETH will take Ethash
    • RVN will take Kawpow
    • Bitcoin will take SHA256 and so on..



Will be thankful and welcome for corrections

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.