Repository navigation
Conversation
Job 1, the opening job, stays 0 transactions and 1 pool output. clean_jobs is already true there. That part is unchanged. Job 2 is the fee template on that same job. It now goes out with clean_jobs true, so the miner is told to leave job 1. Job 3 is the coinbase split that arrives after those two. It is a new job, and that notify also goes out with clean_jobs true. The miner is told to leave jobs 1 and 2 and take the split. The old job is not marked stale, so a share already submitted still counts. The later 40-second refresh stays clean_jobs false and sits alongside.
|
|
|
is it an acceptable loss though? its a very short window... clean_jobs true only tells it to drop the nonce rage in the chips, already submitted are accepts, gateway doesnt set is_sale_prevblock for these jobs this runs twice, once for fee template to replace the empty opening job (still has one pool output though) IF we do not replace them in this way.. the new jobs above run alongside (ANNOUNCED BUT NOT REPLACED) the first one. both jobs are valid... and MAY continue to work and produce one-out valid shares, until it picks up the 3rds job... the pay back In return... for the small discarded hashrate, is instead on fishing the empty or one out template, it takes up the coinbaser split NOW |
|
No, I don't think it's an acceptable loss. The old work is still perfectly valid. |
|
The old work completed is still accepted, as stated, precisely because it is valid. This only also only runs at the start of a new block tip, giving the ability to reduce the number "pool only" coinbaser blocks. Also it is not clear that the hashrate loss is ever even truly accepted in the first place. as many pool reject these share completely, and do not credit work at all. Even if the hash it creates is a valid difficult share. Would making this be configurable, with default to disabled, be an acceptable method? It would allow Gateway runners to sacrifice a very tiny bit of hashrate for less rejected shares, and less pool-only coinbase blocks. note: This does not eliminate the pool-only, only lessen it. |
2 participants
Job 1, the opening job, stays 0 transactions and 1 pool output. clean_jobs is already true there. That part is unchanged.
Job 2 is the fee template on that same job. It now goes out with clean_jobs true, so the miner is told to leave job 1.
Job 3 is the coinbase split that arrives after those two. It is a new job, and that notify also goes out with clean_jobs true. The miner is told to leave jobs 1 and 2 and take the split.
The old job is not marked stale, so a share already submitted still counts. Later jobs (40-second refresh) stays clean_jobs false and sits alongside.
Currently only job 1, on new block, is marked clean_jobs=true, and so job 2 & 3, CAN run alongside each other, resulting in empty blocks, or no coinbaser split despite having a job in que waiting