TProxy responding to mining.submit with result:true for low difficulty shares.

[darricksee]

I created a little test with a simulator which produces low difficulty shares pointing at the tproxy -> pool -> TP. The tproxy handles the shares properly but responds with:

2024-06-26T17:22:16.565280Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Sending to Mining Device: 3.141.43.42:47752 - "{\"id\":4,\"error\":null,\"result\":true}\n" erroneously. It should respond with a "low difficulty" error.

Full logs:

2024-06-26T17:22:16.565062Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Receiving from Mining Device 3.141.43.42:47330: "{\"params\": [\"btcnf1.sim-btcnf192-00005\",\"121\",\"a9cafe98fc283233\",\"667c4e48\",\"667c4e48\"],\"id\":4,\"method\": \"mining.submit\"}" 2024-06-26T17:22:16.565120Z INFO translator_sv2::lib::downstream_sv1::downstream: Down: Submitting Share 2024-06-26T17:22:16.565124Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Down: Handling mining.submit: Submit { user_name: "btcnf1.sim-btcnf192-00005", job_id: "121", extra_nonce2: Extranonce(Owned([169, 202, 254, 152, 252, 40, 50, 51])), time: HexU32Be(1719422536), nonce: HexU32Be(1719422536), version_bits: None, id: 4 } 2024-06-26T17:22:16.565134Z DEBUG translator_sv2::lib::downstream_sv1::downstream: To DOWN: OkResponse(Response { id: 4, error: None, result: Bool(true) }) 2024-06-26T17:22:16.565152Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Receiving from Mining Device 3.141.43.42:47752: "{\"params\": [\"btcpyt2.sim-btcpyt297-00003\",\"121\",\"975b806ef941462c\",\"667c4e48\",\"667c4e48\"],\"id\":4,\"method\": \"mining.submit\"}" 2024-06-26T17:22:16.565163Z INFO translator_sv2::lib::downstream_sv1::downstream: Down: Submitting Share 2024-06-26T17:22:16.565166Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Down: Handling mining.submit: Submit { user_name: "btcpyt2.sim-btcpyt297-00003", job_id: "121", extra_nonce2: Extranonce(Owned([151, 91, 128, 110, 249, 65, 70, 44])), time: HexU32Be(1719422536), nonce: HexU32Be(1719422536), version_bits: None, id: 4 } 2024-06-26T17:22:16.565171Z DEBUG translator_sv2::lib::downstream_sv1::downstream: To DOWN: OkResponse(Response { id: 4, error: None, result: Bool(true) }) 2024-06-26T17:22:16.565186Z DEBUG roles_logic_sv2::channel_logic::channel_factory: Checking target for share Extended(SubmitSharesExtended { channel_id: 936, sequence_number: 0, job_id: 121, nonce: 1719422536, ntime: 1719422536, version: 536870912, extranonce: Owned([169, 202, 254, 152, 252, 40, 50, 51]) }) 2024-06-26T17:22:16.565214Z DEBUG roles_logic_sv2::channel_logic::channel_factory: Bitcoin target: Target { head: 0, tail: 0 } 2024-06-26T17:22:16.565219Z DEBUG roles_logic_sv2::channel_logic::channel_factory: Upstream target: "00000000000001a67855d5296f5f1ef166d767250001d67d7c4dbf373f3d1833" 2024-06-26T17:22:16.565224Z DEBUG roles_logic_sv2::channel_logic::channel_factory: Hash: "773e3f13225945cf8477ce925847c65cdf0db1e72fe30250a64d6bd175f48460" 2024-06-26T17:22:16.565227Z ERROR roles_logic_sv2::channel_logic::channel_factory: Share does not meet any target: Extended(SubmitSharesExtended { channel_id: 936, sequence_number: 0, job_id: 121, nonce: 1719422536, ntime: 1719422536, version: 536870912, extranonce: Owned([0, 0, 0, 0, 0, 0, 3, 168, 169, 202, 254, 152, 252, 40, 50, 51]) }) 2024-06-26T17:22:16.565234Z ERROR translator_sv2::lib::proxy::bridge: Submit share error Ok("difficulty-too-low") 2024-06-26T17:22:16.565239Z DEBUG roles_logic_sv2::channel_logic::channel_factory: Checking target for share Extended(SubmitSharesExtended { channel_id: 984, sequence_number: 0, job_id: 121, nonce: 1719422536, ntime: 1719422536, version: 536870912, extranonce: Owned([151, 91, 128, 110, 249, 65, 70, 44]) }) 2024-06-26T17:22:16.565243Z DEBUG translator_sv2::lib::downstream_sv1::downstream: Sending to Mining Device: 3.141.43.42:47330 - "{\"id\":4,\"error\":null,\"result\":true}\n"

[plebhash]

thanks for reporting this @darricksee

ideally we should be able to reproduce this issue deterministically

I created a little test with a simulator which produces low difficulty shares pointing at the tproxy

would you be willing to share this?

[GitGab19]

@plebhash didn't you just added a MG test fixing this issue recently?

[plebhash]

@plebhash didn't you just added a MG test fixing this issue recently?

https://github.com/stratum-mining/stratum/issues/791 that was for old shares, not low difficulty

I do suspect the fix will be relatively similar though

[GitGab19]

@darricksee always related to this point, I was wondering what's the best approach with regards to stale shares.

Right now Translator refuses shares related to an old job_id (even if it's still valid, meaning based on the correct prev_hash). In https://github.com/stratum-mining/stratum/issues/791 we established that Translator answers with result:false in that case.

But is this approach correct? Shouldn't we refuse shares only when they are based on an old prev_hash? I'm just thinking about the edge case in which Translator could refuse a valid block just because that share is related to an old job. How pools typically manage it?

[darricksee]

@GitGab19 - yeah that's correct. Miners are strongly encouraged to work on the latest jobs as these have the most favorable transactions. Ideally jobs have a long timeout so it shouldn't ever happen.