Open ericecook opened 10 years ago
Even cleverer would be to detect if they're still submitting the last flush vs the last push, and then occasionally send a flush for only those clients. Best of both worlds, but honestly our push timing logic is crazy confusing right now as is, so reasoning about this improvement will get tricky fast.
Cool idea. Might actually be worthwhile to make a utility/test for the flushing logic
Yeah, tests in general are a big thing that is needed... Certainly would be a good place to start since I know there's a related bug right now.
Some (old/crappy) mining clients will simply ignore new work notifications from the server unless it signals to flush old jobs. This is an annoyance for merge mined coins, where you probably don't want to flush for some (lower value) Aux chains.
A potential optimization would be to have a configurable time period where if stratum hasn't pushed a job that flushes to the client in that time it'll proceed to push one.
This has the advantages of not spamming out flushing pushes, but updating a fair bit of stale Aux jobs.
The main disadvantage would be a increase in main chain stales. To mitigate that we could keep the (old but valid) job around and still credit the stale submissions...But then people would need to make sure and configure to send stales...Messy, and not even possible on some miners.
It'd need to be tested/balanced to make sure the increased stales didn't outweigh the increased profits from Aux work...
Overall, quite a bit of work for a slim gain, so its definitely not a priority - just figured I'd put it up for thoughts/feedback. It could be a more valuable feature if merge mined coins continue to grow in popularity