[Maveth]

A pooled gateway used to treat any coinbaser answer, including an empty one, as finished and then publish the local one-output coinbase. While the pool link is up, a result under 2 outputs now waits 500ms rather than 5000ms and asks again. Solo, when the pool link is down, still publishes that one output.

[luke-jr]

Seems like the pool just shouldn't send them? What's the goal here?

[Maveth]

If the pool has a split of the payment outputs, and the Gateway has not yet updated to match. The gateway will make a block that doesnt pay the pools coinbaser outputs.
The goal is for the GW, when connected to a pool, to be more aggressive in asking for the coinbaser splits, when it doesnt have them yet.

[Maveth]

a note, i made the default true, it could be made false.. then nothing changes.. and would be the GW choice to use or not.

[Maveth]

this will not replace the job, a replace feature with clean_jobs=true is required for that, it only ensures that the GW has the split. True effectiveness requires both, but is not required, as this can still help on its own.

[luke-jr]

If you answer coinbaser, it has the split...

[Maveth]

yes IF it answers, but...
right now it waits for 5 seconds, and if it doesnt get an answer it leaves the one-output pool address, while it keeps working, until its (default 40s job makes it ask again)
thus giving multiple rej errors on pool side for coinbaser for all the shares until then...

this just tells its ask again...and again until it gets an answer.
Lessens the risk of a one-out pool address only coinbase and lessens the rejects (if it answers).

[luke-jr]

Sounds like it should just act when it gets the answer it already asked for...

[Maveth]

except it ignores that answer, if it receives it after 5 seconds(this may also be be too long and played with lowering it as well), unit it rejects a new job. If the setting is default (then 40s) then an addition 35 can be spend working on a pool-only coinbaser payout. Despite the fact it received the new split at at 5.05 seconds..

Both of these setting maybe if we dont like wat change the default behaviour be turned into config options?

This would allow a GW user to tune a more aggressive cycle, to avoid pool rejects of bad coinbaser split shares.

As well as improve the GW's ability to produce less pool-only payout blocks. requiring the pool to custody rewards until a manual adjustment can be made.

[Maveth]

real life failure scenario (might require its on fix)
-GW has high latency (Is an ABW active port on pool)

• doesnt get the CB split before the 5 seconds
• pool gives it the split at 5.1-5.5 seconds
• GW ignores it, since past the 5sec limit
• GW keeps hashing for 40s on bad Coinbaser split. )pool only)
• Pool (when in strict ABW mode - after rejects the first few as bad coinbase share, rejects the next 35s (5+35) as non rebuildable verification - or as highhash, because the validation expects the good coinbase so the hash doesnt meet target --- thats more a pool thing but the result is the same...) so all 40s work is rejected... (in less strict mode rejects all as bad coinbase. more accurate)
• GW sees no shares >30seconds.. and restarts connection... SO NEVER uses the split it was given...
  cycle repeats... on a low diff setting, or faster job cycle... it might re-ask and get the split..

So another fix COULD be if no coinbase split, dont do the 40s work, just ask for new job after 5 seconds?