deadline too long?
-
This one is new to me
Example Block 364300
found DL 29885
sent DL 29885 0d 08:18:05
but then came back and said it was too long at 47873 years?if the DL was only 8hrs, why does it think its 47873 years?
-
Just found this thread
http://forums.burst-team.us/topic/4084/error-1088-deadline-for-your-nonce-is-too-long-what-does-this-meanbut it doesn't answer my question above.
Maybe I have a corrupt plot file?
-
@mrgoldy try another miner
-
@ccminer
So this whole time I've been using the AIO CPU miner, with no problems, and just now I see this, and it's a miner issue?
I guess I'll have to look into the gpuminer setup and see if the problem still occurs.
-
@mrgoldy it will not! I'm quite sure
-
@mrgoldy If it happens one time it's ok, if it happens repeatedly you may have a corrupted plot file...
Regarding to what happened if it happenned one time, it had to do with the way the pool, decrypted your nonce and DL, provably due to the pool having so much DLs to confirm... If the pool you are on, it's taking some time to confirm you the DLs you sent to it, I would recommend you to warn the pool owner and maybe switch the pool so one with less miners! Provably the pool is overflowed with DLs to process and sometimes can go wrong ;D
-
This post is deleted!
-
@PingOfd3ath I guess it makes sense ;D
-
@mrgoldy Hi, william here a newbie on burst mining!!! I need help in understanding exactly what confirmed DL's mean like the last one in your above screenshot:" 599731 6d 22:35:31. Do you need to do anything after this confirmation or just have to wait??? I am mining at a very small scale (249gb) and get appr 10-15 confirmations for the last 3 days but my account gets credit with 1.??? per day. I need to understand this payout concept better before upgrading to Tbytes.
Pardon me with all my questions but I don't get proper answers on the forum. Many thanks.
BURST-2RTV-2E8J-RRDU-6L42H
-
@mrgoldy
My theory: You received mining info from pool and miner is using that ... but the pool was on the wrong block. So the pool switched to correct block, meanwhile the miner still uses the old mining info that he initially received. That leads to miner thinking he has good deadline while pool says he has not.
As far as i know, there is no miner yet, that stops and restarts current round if not only block height but generation signature for same block height has changed.



