search

decred / gominer

Go (golang) based GPU miner for Decred.
GNU General Public License v3.0
160 stars 80 forks source link

Multiple solutions submitted for single template #203

Closed jholdstock closed 1 year ago

jholdstock commented 1 year ago

All of the results returned by a single execution of the CUDA kernel are submitted to dcrd, despite being solutions for the same block template. I'm not sure if this is deliberate or if it constitutes a problem, but it seems wasteful and can cause unnecessary orphan blocks to be broadcast around the network.

https://github.com/decred/gominer/blob/d725cda10e79b05246def1e38215582cc2c83366/cudevice.go#L390-L403

2023-09-07 08:54:02.065 [TRC] MINR: pre-nonce: 0b0000007ac081ed0cbf8dc16f92e4cb4c39b4462b3e85ca762996dbd87792031eb338b2e6badf4eb5c541ba6063eb982d4318d6f7a0e2f0b113f7e53e42fa9d91c0bead54e24acc37539412b64ac7e9f31941bb477a9cfa7680e45569645a5155daf4ea01008c89fe2ddcf90500000013140000900f1f1d3f173455010000000f6e1200522100009a81f9640000000000000000000000000000000000000000000000000000000000000000000000000b000000000000000000000000000000
2023-09-07 08:54:02.065 [TRC] MINR: midstate input data for work update 0b0000007ac081ed0cbf8dc16f92e4cb4c39b4462b3e85ca762996dbd87792031eb338b2e6badf4eb5c541ba6063eb982d4318d6f7a0e2f0b113f7e53e42fa9d91c0bead54e24acc37539412b64ac7e9f31941bb477a9cfa7680e45569645a5155daf4ea01008c89fe2ddcf90500000013140000900f1f1d3f17345501000000
2023-09-07 08:54:02.065 [TRC] MINR: work data for work update: 0b0000007ac081ed0cbf8dc16f92e4cb4c39b4462b3e85ca762996dbd87792031eb338b2e6badf4eb5c541ba6063eb982d4318d6f7a0e2f0b113f7e53e42fa9d91c0bead54e24acc37539412b64ac7e9f31941bb477a9cfa7680e45569645a5155daf4ea01008c89fe2ddcf90500000013140000900f1f1d3f173455010000000f6e1200522100009a81f964000000000000000069e6134d5500000000000000000000000000000000000000000000000b000000000000000000000000000000
2023-09-07 08:54:02.563 [DBG] MINR: GPU #0: Found candidate 0 nonce 55cb4a5f, extraNonce 7b056ff3, workID 4d13e669, timestamp 64f9819a
2023-09-07 08:54:02.563 [INF] MINR: DEV #0: Found hash with work below target! 000000008fca2334fb91734f82676ff190fd5aba9deba396f49a8dbfec94a183 (yay)
2023-09-07 08:54:02.563 [DBG] MINR: GPU #0: Found candidate 1 nonce 74dd09d0, extraNonce 7b056ff3, workID 4d13e669, timestamp 64f9819a
2023-09-07 08:54:02.563 [INF] MINR: DEV #0: Found hash with work below target! 000000008919fa497d4a01fdf166df559ccc21b1450c77e037aa538ca57dc85c (yay)
2023-09-07 08:54:02.563 [TRC] MINR: GPU #0: Kernel execution to read time: 497.976814ms
jholdstock commented 1 year ago

Seems to apply to all other device types, not just CUDA

davecgh commented 1 year ago

It's pretty standard behavior for miners. They generally don't throw away any solutions. One major reason is that it's typical for them to submit solutions to lower difficulty targets to pools which the pool then checks if it's actually a solution to the real network target. The submissions act as partial shares that prove they are doing useful work in order to be eligible for their relative portion of pool payouts. Multiple submissions demonstrates more work and thus increases their relative payout.

Another one is they can't really be sure if a submission will be orphaned or not, so it could be the case that their first block is orphaned and then they threw away another valid solution that might itself have been selected to build on.

I know that it's especially noticeable on low diff networks like testnet/simnet, but with any real difficulty levels when solo mining it rarely happens in practice. On the other hand, when pool mining, you want to submit every solution for the aforementioned reason.

jholdstock commented 1 year ago

OK great, so long as it isnt a bug I guess this can be closed.