Bitcoin Forum
November 12, 2024, 06:15:08 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: SmartXMR.com - efficient XMR mining pool  (Read 152 times)
mozzar (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
July 25, 2018, 12:51:35 PM
Last edit: July 25, 2018, 04:39:37 PM by mozzar
 #1

We are pleased to introduce you a new mining pool for effective mining Monero.

Differences from all existing pools:
The search for a solution is made consistently, miners work in concert, each miner gets his part of the work and looks for a solution in his own range.
Accordingly - significantly lower hash rate is required to mine blocks in comparison with conventional pools.

After reading https://cryptonote.org/cns/cns003.txt we understand that
"... the miner should iterate number " nonce " in the header of the block and hash the block again and again until the hash value satisfies a certain condition ... "

The size of "nonce" number is 4 bytes or 4294967296 of possible values, which need to be scanned out for 2 minutes.

The required speed for scanning the entire range is 4294967296/120 = 35791394 H/s or 35.8 MH/s.

Thus, having total hash rate on the pool of 35.8 Mhash / sec, we are guaranteed to find the block in maximum for 2 minutes. It does NOT depend on the difficulty of the network - we went through all the combinations of "nonce" for 2 minutes!

Retreat:
let me tell you how all existing pools work: the search for a solution is not consistently, all the miners start the search from scratch when the new block appears and perform the same task (assume - all pool miners use the xmr-stak program, then when a new block appears, all begin searching from "nonce" = 0, 1, 2 ...) which is extremely inefficient.

As a consequence - all low-speed miners on the pool do not do any good for the purpose of finding the block ...

So, let's continue:
suppose that our pool will collect hash rate in a quarter of 35.8 MH/s, just 8.95 MH/s.
Statistically, we will be able to find a quarter of all the blocks found during the day ie. 180 blocks or in terms of reward per block 180 x 4 xmr = 720 xmr. As a result, each miner has reward of 0.08 xmr from 1 KHash per day, which is more than exceeds reward on existing pools.

Of course, with this approach, there are many technical issues that we tried to solve in our own implementation of the mining pool and the mining program.
Mining on the pool is possible only with the xmr-stak-smart program (cpu + amd, nvidia is not supported). Based on xmr-stak, substantially redesigned algorithm and stratum protocol of interaction with the pool.

Pool address: smartxmr.com
e-mail: smartxmrpool@gmail.com
The xmr-stak-smart mining program can be downloaded from the site in the "Getting Started" section.

The project is at the testing stage, in order to confirm the effectiveness of the implemented solution, miners are needed. Pool fee is 0. The minimum payment threshold is 0.1 xmr.
There is a proportional reward distribution system for the block(in proportion of the miner hash rate).

We will be glad to the miners with low hash rate. Even mining on processors will benefit in finding the block on our pool.

Who is ready to participate in the project - you are welcome!
I apologise for my bad English.
mozzar (OP)
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
July 26, 2018, 08:06:26 AM
 #2

Let me briefly explain the essence of the implemented algorithm of our pool and the xmr-stak-smart program.

Each miner of our pool, taking into account the speed of its equipment (hashed) dynamically gets its range from the interval [0 ... 2 ^ 32-1] to search for a hash and looks for a hash that satisfies the current complexity of the network. There is no concept of local complexity.

For comparison, on existing pools, the search algorithm looks like this:
let the miner have 2 rigs with a speed of 10 KH / s each and each program xmr-stak is running. When a new block appears, each of the rigs starts to search for a solution from scratch! that is, both rigs do the same work in parallel and in a second they will calculate only 10 thousand different hashes and the effective speed of this miner for the purpose of finding the block will be the same 10 KH / s. (an analog of some kind of mirroring / duplication of calculation)
And on the pool, the speed of the miner will be counted as 20 KH / s, although actually the miner sorts out 10,000 different combinations per second.

With the correct tasks tasking, on our pool the same miner would go over 20 thousand different combinations per second!
Therefore, it is not correct to compare the hash of our pool and all other pools.

I hope I managed to clarify a little the essence of the algorithm of our pool and a fundamental difference from all other pools.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!