5

I received a mining job with target = f3220000.

My XMRig miner logged the following statement:

new job from ... diff 480045 algo rx/0 height 2027084

I want to find answers to the following questions:

  1. How to get a decimal value of difficulty (480045) by a hexadecimal value of a given target in hex (f3220000) ?

  2. How to get a hexadecimal value of target (f3220000) by a decimal value of a given difficulty (480045)?

My research led to the following formula: target = targetmax / diff when targetmax = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

I also found the something in the source of some pools here and here. They have a different logic and I can’t understand it anyway.

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
Andrei
  • 367
  • 1
  • 8

1 Answers1

6
  1. How to get a decimal value of difficulty (480045) by a hexadecimal value of a given target in hex (f3220000) ?

Swap endian f3220000 and remove padding gets 22f3, then 0x100000001 / 0x22f3 yields: 480045.

  1. How to get a hexadecimal value of target (f3220000) by a decimal value of a given difficulty (480045)?

((2^256-1) / 480045) >> 224 is decimal 8947, hex 0x22f3. Swap endian and pad yields: f3220000.

The reason for both the division in #1 and shift in #2 is because we are exploiting the fact that we are working with only a 32 bit difficulty target. Thus, we are only concerning ourselves with the most significant 32 bits of a 256 bit number.

It's worth noting that this calculation is just legacy hangover of how the pools and miners were doing this when forked, which nobody felt strongly enough to improve upon. The current miner implementations foresaw this 32 bit limitation and do have code to handle larger targets [ref], though most pools do not, as can be seen by the pools you cite. In retrospect, it would probably be more sensible if the pools and miners calculated/checked difficulty more akin to how Monero does (i.e. if hash multiplied by difficulty doesn't overflow, it's good), as whilst this would mean passing around a slightly larger target in the stratum job message, it's more future-proof.

jtgrassie
  • 19,111
  • 4
  • 14
  • 51
  • Thank's a lot! Swap endian is not very obvious. Can you can add a little more detailed answer? Or give resources that will help me? I would be very grateful! – Andrei Feb 05 '20 at 22:59
  • And ">> 224" is not very obvious too =( – Andrei Feb 05 '20 at 23:05
  • 1
    Max diff is 2^256-1 and we are only working with a 32 bit difficulty target. Hence >>224 is shifting out the bottom 224 bits from our division of the base diff to take only the top 32 bits. – jtgrassie Feb 05 '20 at 23:52
  • 1
    "Swap endian is not very obvious. Can you can add a little more detailed answer?" <- You want to know how to swap endian? – jtgrassie Feb 05 '20 at 23:55
  • No, I know what is "swap endian". My question is why operation "swap endian" is applied in this case. – Andrei Feb 06 '20 at 00:33
  • 1
    Why someone decided to use BE byte order vs LE in the stratum message is really not relevant. It is in that byte order so you need to swap. – jtgrassie Feb 06 '20 at 00:43
  • Difficulty = 200000. ((2^256-1) / 200000) >> 224 is decimal 21474, hex 0x53e2. Swap endian and pad yields: e2530000. – Andrei Apr 07 '20 at 13:36
  • Target = e2530000. Swap endian 53e20000 and remove padding gets 53e2, then 0x100000001 / 0x53e2 yields: 200007. Its should be 200000. What I'm doing wrong? – Andrei Apr 07 '20 at 13:41
  • 1
    You are just witnessing rounding at play. E.g.0x100000001 / 200000 = 21474.836485 is a float, and the reverse calc/truncation (with the shift), is using integers, thus you won't always get an exact match both ways. – jtgrassie Apr 08 '20 at 07:51
  • So I can not send the work to the miner with the difficulty of 200000? I think I mined on pool.supportxmr.com:3333 and got this kind of work with difficulty of 200000 – Andrei Apr 08 '20 at 08:49
  • 1
    Pools send jobs to miners, which work and then send the result (a hash) back to the pool. If a pool asks you (miner) to meet a target of 0x53e2, the top 32 bits of your hash (256 bit number), need to be less than 0x30d47 (200007). – jtgrassie Apr 08 '20 at 09:29
  • Several days ago output of xmrig showed me the job with the difficulty of 200000. Then what target was sent to me? Or is it impossible? – Andrei Apr 08 '20 at 09:41
  • 1
    If XMRig prints a diff of 200000 then the pool sent a target of 0x53e2 (so in the stratum message format e2530000). As already mentioned, because there is rounding at play in the calculations above, you wont always get exact matches in both directions of the calculations - e.g. if the jobs target was 1 bigger (0x53e3), that would be difficulty 199998. – jtgrassie Apr 08 '20 at 17:18
  • Sorry, I'm now trying to convert current mainnet difficult 147640361901 to target (hex) ((2**256-1) // 147640361901) >> 224 and got 00000000. Why I have all zeros if using your formula ? – Andrei Apr 16 '20 at 01:42
  • 2
    You can't convert mainnet current difficulty to stratum's 32 bits, it's too big. The current miner implementations, any hex string bigger than 4 bytes (8 chars) is treated directly as the target, no conversion. See the last paragraph of my answer. – jtgrassie Apr 16 '20 at 01:57