Not solvable at 50% edge easiness?

[Metric]

I have been playing around with the java version and noticed that it never really finds a solution on pretty much most things at 50% edge easiness. I usually have to bump it up to about 56% to find a solution. Which, seems odd, considering that it should be able to find a solution at 50%. I only ever see the cycle print out when it reaches about 75% or more the way through the nonces.

example of one at 56%

ith 56% edges and 1 threads
 14-cycle found at 0:85%
 18-cycle found at 0:87%
 26-cycle found at 0:88%
 20-cycle found at 0:89%
 72-cycle found at 0:89%
 194-cycle found at 0:91%
 168-cycle found at 0:91%
 174-cycle found at 0:91%
 14-cycle found at 0:92%
 24-cycle found at 0:92%
 380-cycle found at 0:92%
 180-cycle found at 0:92%
 104-cycle found at 0:92%
 356-cycle found at 0:92%
 310-cycle found at 0:92%
 212-cycle found at 0:92%
 28-cycle found at 0:92%
 254-cycle found at 0:92%
 300-cycle found at 0:92%
 306-cycle found at 0:92%
 414-cycle found at 0:92%
 86-cycle found at 0:92%
 386-cycle found at 0:92%
 202-cycle found at 0:92%
 302-cycle found at 0:92%
 376-cycle found at 0:92%
 200-cycle found at 0:92%
 144-cycle found at 0:92%
 334-cycle found at 0:92%
 366-cycle found at 0:93%
 114-cycle found at 0:93%
 362-cycle found at 0:93%
 264-cycle found at 0:93%
 394-cycle found at 0:93%
 136-cycle found at 0:93%
 130-cycle found at 0:93%
 118-cycle found at 0:93%
 318-cycle found at 0:93%
 118-cycle found at 0:93%
 202-cycle found at 0:93%
 182-cycle found at 0:93%
 98-cycle found at 0:93%
 30-cycle found at 0:93%
 150-cycle found at 0:93%
 152-cycle found at 0:93%
 352-cycle found at 0:93%
 208-cycle found at 0:93%
 188-cycle found at 0:93%
 340-cycle found at 0:93%
 366-cycle found at 0:93%
 128-cycle found at 0:93%
 128-cycle found at 0:93%
 218-cycle found at 0:93%
 260-cycle found at 0:93%
 446-cycle found at 0:93%
 306-cycle found at 0:93%
 238-cycle found at 0:93%
 368-cycle found at 0:93%
 408-cycle found at 0:93%
 186-cycle found at 0:93%
 276-cycle found at 0:93%
 260-cycle found at 0:93%
 342-cycle found at 0:93%
 42-cycle found at 0:93%
 326-cycle found at 0:93%
Solution 7d25 7eb5 961a fb19 103d2 13606 16320 204ab 20b7a 242e0 24429 25398 29025 310fc 31472 33113 37910 3a6cf 3de2b 3fb9b 41bc1 459e5 4e794 4fe98 54153 57949 57b3a 57ed3 58cc6 5e676 60627 68077 7374a 73b9f 747b5 7507c 7694a 7a0e8 7ba83 83e0e 840e6 8690f

vs what I get at 50%:

with 50% edges and 1 threads
 14-cycle found at 0:95%
 18-cycle found at 0:97%
 26-cycle found at 0:99%

with no solution found at all.

Am I missing something here on how it is suppose to work?

[tromp]

dear Metric,

I have been playing around with the java version and noticed that it never really finds a solution on pretty much most things at 50% edge easiness. I usually have to bump it up to about 56% to find a solution. Which, seems odd, considering that it should be able to find a solution at 50%. I only ever see the cycle print out when it reaches about 75% or more the way through the nonces.

vs what I get at 50%:

with 50% edges and 1 threads 14-cycle found at 0:95% 18-cycle found at 0:97% 26-cycle found at 0:99%

with no solution found at all.

You're not expected to find a solution on most instances. Instead, each graph has an expected small number of cycles, with the probability of a particular cycle length being roughly inversely proportional to the length. So a 42 cycle appears only in roughly 2% of all graphs.

Am I missing something here on how it is suppose to work?

It's supposed to take some luck to stumble on a graph with a 42 cycle. Try running a few hundred instances and you'll see them.

regards, -John

[Metric]

I see, so basically the block itself will still require a secondary nonce or wait until a transaction is added that changes the hash that provides a solution. Is this assumption correct? Otherwise, if the block hash never changes, then it would never find a solution.

[tromp]

dear Metric,

I see, so basically the block itself will still require a secondary nonce or wait until a transaction is added that changes the hash that provides a solution. Is this assumption correct? Otherwise, if the block hash never changes, then it would never find a solution.

Yes; you still use a regular nonce to mine this. Each header and nonce determines a graph in which you look for a 42-cycle. Which is then witnessed by 42 edge indices (which I used to call micro-nonces).

regards, -John