need help modifying cgminer/hashfast to create proofs with more leading zeros

[BitcoinSoloMiner]

We are attempting to modify the miner code to create proof with more leading zeros...


cgminer/hashfast code:

https://bitbucket.org/ckolivas/hashfast/src/hashfast/

example output:

Code:

Proof: 00000000e1e6043fa5689c5e54d1ba4caff323a7415c5387f852bd6c8cb3e26c
Target: 0000000000068db2ffffffffffffffffffffffffffffffffffffffffffffffff
TrgVal? no (false positive; hash > target)                    
Share below target

in the above example we can see that the proof contains only 8 leading zeros, the generated work contains 8 zeros but fails to meet the target of 11 zeros

It seems even after some runtime, work/proof containing more than 8 or 9 or 10 leading zeros is not produced:

Code:

 [2022-12-22 05:06:38]  Proof: 000000002ec40f195f3374089456d4f105909cbf4dcf5dcadd4aea1aecfd25a6
 [2022-12-22 05:06:40]  Proof: 0000000029f29347e9b0d42962d6f661404d234a2f543e05b18edfb5330c7fe3
 [2022-12-22 05:06:42]  Proof: 00000000a90a3de09d2abdd819c1625716bdc26c13973f13d3038ba4a5d00e75
 [2022-12-22 05:06:44]  Proof: 00000000cc4928d97fd68097d9ae16253250aa3371938d037fa1325e480fb079
 [2022-12-22 05:06:50]  Proof: 000000005ea8b5d09725d55ffb3a525994d2ae116c246f316c85981c0a74a1f3
 [2022-12-22 05:06:53]  Proof: 000000000bd06bfb227f02cfca4bacf52019afda29a6cf71d487b0ff9b630ab8
 [2022-12-22 05:06:53]  Proof: 000000007680b38625214fa1ff7d3194e3bd0e05cdbe439ad42845c9a9051882
 [2022-12-22 05:06:54]  Proof: 000000009f72dc47c35ffe490a1aff7b3a634eb0d3b75a6427b3ea8c53ad9067
 [2022-12-22 05:06:59]  Proof: 00000000e3fa5675607e8825be191a1f68d94b9217dbf050f0b3a0ef4ff351a8
 [2022-12-22 05:07:01]  Proof: 0000000061cf8e194e463dfc2b194bf1f95ac00901418e2e26ce9dbf988db33b
 [2022-12-22 05:07:02]  Proof: 00000000a047159116a39eae893cee5319149c363e4beb2e13efb68b0691df35
 [2022-12-22 05:07:06]  Proof: 00000000946da38c443690713a250ca8ca23b9839c55141874b5d9c4f8c62ace
 [2022-12-22 05:07:11]  Proof: 00000000cf989a94ae5c7cf93d32479e71596eb73a495dfceb9cbfa29611a13a
 [2022-12-22 05:07:11]  Proof: 00000000ebe732a8cd43cc3d99f4f8d25d5ec9ae57736589c812d85c23e9467d
 [2022-12-22 05:07:13]  Proof: 000000002d64313147f8ddfabf2630f8753bc55ab6c7c085cc01534b0f751da7
 [2022-12-22 05:07:14]  Proof: 0000000013a74911fa177010027b731d9ba6fba242e5627f51123a36afd7f008
 [2022-12-22 05:07:14]  Proof: 0000000013dc35a4e1e3ff0e6f3d3e5b618656e3555f38e0ddc7b56db0fc712f
 [2022-12-22 05:07:15]  Proof: 000000009e9759fd7eed957979cb03ecde4185ac8e29e593d776bfb332f4ae1f
 [2022-12-22 05:07:17]  Proof: 0000000087840096a2d88ae7daea8a0fc0febc38175ad438a12145becaf0c134
 [2022-12-22 05:07:19]  Proof: 00000000e4d015e0cbf2bb79a1bc39abe613725b62892a486cb86184e9bd693a
 [2022-12-22 05:07:20]  Proof: 000000008838f166e31d896e2dfb7025f595a828b101f6f248ce66dc54f10b20
 [2022-12-22 05:07:20]  Proof: 00000000349a569d338b56a9bf211b766892624aec9b07b56e60fada14e23323
 [2022-12-22 05:07:20]  Proof: 0000000013e5ab0f20155d377636741959a8f26491a49585e5737a236ee90589
 [2022-12-22 05:07:21]  Proof: 000000005543f3add031189d02775de297044e2374faa0eab05db32abc01935d
 [2022-12-22 05:07:23]  Proof: 0000000044fe3536d2100481eaa11d28c221f2f8eb6423170e81014bc6269612
 [2022-12-22 05:07:24]  Proof: 000000000bc3e6eddd8a1b0944f41c0d094553ea87d69b317195628c3bb84b68
 [2022-12-22 05:07:27]  Proof: 0000000063de0951cf83a2a62bd11757382c300930442509301caa8771178d8e
 [2022-12-22 05:07:27]  Proof: 000000005613d2ee2e67e69d6935274b8fa93c4d68d96a4f81e9de03dfdce588
 [2022-12-22 05:07:28]  Proof: 00000000b00fc850a25fe3c7d55542602bcdfa0037ca01a2b535b242f472cb85
 [2022-12-22 05:07:33]  Proof: 000000004e94fb0ce4b2b274c2e6d1b0679e352eb69cbf3e2557cc60a0dc408b
 [2022-12-22 05:07:33]  Proof: 00000000443f4c185da063289c1b91b4b99e9c806d6fccc3478c573977e3cbf8
 [2022-12-22 05:07:37]  Proof: 000000004d3c9375862c21f07a3ac9528ab9c2d4b7364cca4b88a42986d6a9d8
 [2022-12-22 05:07:37]  Proof: 000000004b87746e5eb9bcc8aea6a0b95a95beaccf2acdb6ba425c53acb1d6ff
 [2022-12-22 05:07:38]  Proof: 00000000d012cbf8e74ea85de5cfe135513c2b8287f7d5b39e4cf1af166acbb8
 [2022-12-22 05:07:38]  Proof: 000000006c702ff1b267810ac5409d0ae75f073698898a415ae2215f93ed7220
 [2022-12-22 05:07:39]  Proof: 0000000083539915deacc0688efd030361f8e8c7a0c7051277dc52cccb750589
 [2022-12-22 05:07:40]  Proof: 000000005a06c2d6b6297c15e782a2d1994af2784edc165d9fbe463633d3dc33
 [2022-12-22 05:07:42]  Proof: 00000000f381ce8244a513beba6e5487536e387307876ae9634e53ac05aa6bdf
 [2022-12-22 05:07:43]  Proof: 000000005b18b1c913e40d0eb87d084e5eba24ebfd182cb2f890347f1e638fe5
 [2022-12-22 05:07:43]  Proof: 000000002c03a65d81605817bb904af9a8936429f658d7244b475154e82bfeb3
 [2022-12-22 05:07:44]  Proof: 000000004eb4ceb510642cffdc65fcba43b4b21d94495216298d330f3aa74e50
 [2022-12-22 05:07:46]  Proof: 00000000929bf93e072d8f35635a260b610cee27332c27d075df0b4dea6c157d
 [2022-12-22 05:07:47]  Proof: 000000000254bc4b5f7b51bcdbb29a921d3f2a8b6a131dff935483343578fa4e
 [2022-12-22 05:07:48]  Proof: 000000008ab54428c887fab82883d28a32bb1286a5ec9f52b38f24ad26610502
 [2022-12-22 05:07:50]  Proof: 000000002b4b2d5cb6f7c35be09297b31b31df08bae8238d4804fc4e790fffab
 [2022-12-22 05:07:50]  Proof: 000000009308c4eaf6ff8895b5296606c991b8f4c59043daf6492ab0230169da
 [2022-12-22 05:07:51]  Proof: 000000006b1426607b691d044716aa543ee4cb9314983616e2379efb2172efa2
 [2022-12-22 05:07:56]  Proof: 0000000085e143b253c5b7e9ae7066021de1a425dbabccd4934f8cfe5778b7d0
 [2022-12-22 05:07:56]  Proof: 00000000e7a66f264fd411f68478dd2648eb493e57ae3edae54e54a42947c477

10 leading zeros:

Code:

 
 [2022-12-22 05:39:49]  Proof: 0000000000c37eea0a9ef2bdac4d4cb71f9b3a951ba501daa0f337359bae72f3
 [2022-12-22 05:42:43]  Proof: 0000000000a67e8767477b224da8aba793c9632aeac378eaeaaaacf94e7d2552

We would like the miner to produce proof with more leading zeros and not even consider/produce anything with less than, say, 11 zeros.

We've tried to find some variables to change in cgminer.c and driver-opencl.c, hoping to find a 'leading zeros = 8' or something, but unable to find anything so far.

We realise that perhaps hashing just cant be configured to produce a certain number of leading zeros and thinking of just letting it run a lot longer

However we are confident this code can be made faster in some way given how opencl/c/bandwidth/resources have advanced in the past 10 years since the time this code was produced


Any advice? Perhaps links to some learning resources in order to code something from scratch?

Perhaps some insights into sha256 collision attacks to create similar proofs?

Perhaps we can modify nonce length parameters like ckpool code allows?

Just to clarify, this topic is in the interests of academia

[1715654546]

1715654546

[1715654546]

1715654546

[1715654546]

1715654546

[kano]

The hash process has a 3% performance gain realising that we want H=0 (32 bit leading zeros)
since we have the value of H before completing all 64 steps of the 2nd internal hash (the 3rd hash of the double sha256)
For G=any number of leading zeros (1 to 32), there is no early shortcut, since H must be 0.

The whole mining process is an exceptionally simple brute force hashing to get leading zeros.
So if you want any particular bit to be zero, it's a 50/50 chance.
If you want any 2 particular bits to be zero, it a 1/4 chance.
If you want 32 bits to be zero it's a 1 in 2^32 chance.

As for "sha256 collision attacks" - they don't exist.
If they did then you'd be best attacking the first 1000000 BTC mined sitting in publicly known BTC addresses.

If you want the miner to return nonces that hash with more than 32 leading zeros (exactly how asic mining works)
then 2 things:
1) if you want 3 more leasing zeros it will, on average, take (2^3) or 8 times longer per nonce found - statistical fact you can't avoid.
You can't speed this factor up.
2) you have to change your code to filter the nonces it already finds, that already have 32 leading zeros.

Since a GPU takes multiple seconds to even find a single H=0 nonce,
no one ever cared about (or ever would care about) getting too much data back from the GPU
The miner will hash it again and check if the hash has as many leading zeros as is required by the pool or bitcoin,
since a CPU can do more than 10 million a second, doing 2 every few seconds - who cares.

With a simple tiny 300GH/s USB asic, (that is 150 to 300 times faster) it finds, on average, only ~70 nonces per second, so even that isn't really a big deal, but I still set the ticket mask to ignore nonces with less than 4 leading zeros in G.

[BitcoinSoloMiner]

is the current difficulty 8 leading zeros, or more, say 11? or 19?

it seems to be 11 from the target value in cgminer:

Code:

Target: 0000000000068db2ffffffffffffffffffffffffffffffffffffffffffffffff

or from what im seeing on bitcoind for recent blocks it is at least 19 or 20 zeros:

Code:

2022-12-22T10:49:56Z UpdateTip: new best=000000000000000000033329b71affc5cff6f7a78e230426dd10071ebd6fd655 height=768477 version=0x20000000 log2_work=93.908143 tx=790072494 date='2022-12-22T10:49:29Z' progress=1.000000 cache=35.1MiB(262405txo)
2022-12-22T11:10:15Z UpdateTip: new best=00000000000000000000e98dde9ab8bba25465d00ab4ca0b72846d2108f8bbf7 height=768479 version=0x20180000 log2_work=93.908166 tx=790078487 date='2022-12-22T11:10:02Z' progress=1.000000 cache=36.7MiB(275218txo)

[kano]

When I say leading zeros above I mean bits, not half bytes.
32 bits of zeros in hex is 00000000 - each 0 is 4 bits for a total of 32 bits.

[BitcoinSoloMiner]

yes exactly... so:

is the current difficulty 8 leading zeros or more?

[kano]

19 (if you mean the network difficulty to find a block)
https://kano.is/index.php?k=minedet

[BitcoinSoloMiner]

So how does one modify the cgminer code to filter out the nonces it has found with less than 19 zeros?

Also:

Code:

Target: 0000000000068db2ffffffffffffffffffffffffffffffffffffffffffffffff

why is cgminer reporting a target with 8 zeros? is it just the outdated hashfast/cgminer code im using?

[kano]

As explained above

https://bitcointalk.org/index.php?topic=5430939.msg61480309#msg61480309

[BitcoinSoloMiner]

can a moderator please move this back to the original subforum?

to quote the rules:
https://bitcointalk.org/index.php?topic=2415854.0

Code:

Discussion of software for education purposes to understand mining related functionality can go here.

[JayDDee]

The short answer is the miner hasn't found one yet. Share production is random, you can't influence that.
The only way to improve that is a faster miner that can test more nonces faster.

The debug logs you are seeing is the result of second level filtering done by software. The first level is done in the ASIC
and you never see the discarded results. The first level filter is as described above by testing the value of H at round 60.
Passing this test does not guarantee the share will be valid but it deserves a closer look. Since the seond level filter never passed
no valid shares were found yet. Each additional bit of difficulty requires double the effort and consequently double the time.