2

Do I understand everything correctly? The pool gives the task to the worker (proxy in our case), like this:

{"id": 1, "jsonrpc": "2.0", "error": null, "result": {"id": "42d954ef-ceee-446c-b2ea-f95c421df573", "job": {"blob" : "02028eb4bcd40519fb82d0d47097f00022d6792976051dd53d86d0718ff029fdc3803d4077a9f1000000004afa5cfe5901bfef02bbc4e29f3a960bf2dfd29a123dd942b9ab6b90673c493503", "job_id": "Wjc5VI / ANH3mAnkhaKtw0WSeJP9h", "target": "b88d0600", "id": "42d954ef-ceee-446c-b2ea-f95c421df573"}, "status": "OK"}}

where the blob is the task itself, which is parsed based on this documentation https://cryptonote.org/cns/cns003.txt

The proxy breaks the blob into parts with a lower diff and distributes to the connected workers based on their capabilities. Then, proxy collects everything in a one job result and send it to the pool. Am I right?

qpi
  • 121
  • 3

2 Answers2

1

The pool sends the job to the proxy.

The jobs blob already has extra space reserved which the proxy adds a worker id to so that each worker (miner) connected to the proxy has their own unique blob to hash.

The target of the job is adjusted by the proxy for each of its connected miners based on how quickly each miner is hashing jobs.

When miners send results to the proxy, they are forwarded onto the pool (after some basic checks).

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • Can you explain how "the proxy adds a worker id"? Proxy receives from pool a blob something like 02028eb4bcd40519fb82d0d47097f00022d6792976051dd53d86d0718ff029fdc3803d4077a9f1000000004afa5cfe5901bfef02bbc4e29f3a960bf2dfd29a123dd942b9ab6b90673c493503. How to convert this blob to a unique block for worker? How to do with the block template is understandable. – Andrei May 28 '20 at 22:37
  • 1
    Parse the blob to a block and overwrite some bytes in the miner tx extra. Every Monero pool I know of reserves 4 bytes and uses the first 2 bytes, so a proxy can use the other 2 bytes. Some proxies will split the block nonce space instead, inserting a miner specific id in there instead. – jtgrassie May 28 '20 at 22:58
  • If we will insert "some bytes in the miner tx extra" then we will change the original blob from the pool. Proxy worker will find a nonce for the modified blob. This nonce is not suitable for the initial (not modified) blob from a pool to which the proxy is connected. Please, help resolve my misunderstanding. – Andrei May 29 '20 at 15:43
  • 1
    If the pool has detected a proxy, it passes along extra info for the proxy to handle inserting bytes. E.g. src. Then when the proxy submits work, it also supplies the extra data. E.g. src. Of course if you are not using this method, and split the block nonce, this doesn't apply and is not required. – jtgrassie May 29 '20 at 20:37
  • Thank you very much! I did not specify the correct user agent in my requests. – Andrei May 29 '20 at 22:47
0

The blob is the block's header.

The proxy breaks the blob into parts with a lower diff and distributes to the connected workers based on their capabilities. Then, proxy collects everything in a one job result and send it to the pool. Am I right?

Mining pools do not stick bits of work together. Any shares that you send with a lower difficulty than the network difficulty are worthless to the pool. Whenever any share is sent with a higher difficulty than the network, the reward is distributed among miners.

Miners send their low difficulty shares to the pool so that the pool knows that they are attempting to find a block.

Matthew Smith
  • 451
  • 3
  • 9