DLs not confirmed how to resubmit



  • I've read in other threads for pools that you should not worry about not confirmed DLs that the pool was probably just to bust to confirm but the DL is in the current shares list. Not sure I believe that 100% as I've seen times when the DL was reported not confirmed and I looked in the current share list and it was not in there. I would shut the miner off and restart and the DL was resubmitted and confirmed and showed up on the current share list.

    What about solo mining?

    If a DL is not confirmed I believe it will not win a block.

    Who is confirming solo mining DLs? Is it the "network"?

    So in a pool, does the pool confirm the DL but then it has to rebroadcast it to the "network"?

    Is there a setting in the miner.conf file to allow a better chance of not receiving not confirmed DLs?

    Is there a setting so that if your DL is not confirmed it will resubmit?

    Thanks for any help.



  • No one???



  • @rds I have seen the same problem many times, made worse I think by my poor Internet connection. I raised the issue on Blago's miner thread, with a suggestion that a retry could be added.

    @RichBC said in Blago's Burst-Miner (Win):

    It got a positive response, so we will hopefully see something in a later release.

    Rich



  • it will be better you show expert here the sreenshoot , so thaat they can has solution to your the issue



  • said in DLs not confirmed how to resubmit:

    I've read in other threads for pools that you should not worry about not confirmed DLs that the pool was probably just to bust to confirm but the DL is in the current shares list. Not sure I believe that 100% as I've seen times when the DL was reported not confirmed and I looked in the current share list and it was not in there. I would shut the miner off and restart and the DL was resubmitted and confirmed and showed up on the current share list.

    Ah the deadline issue. Deadlines are only accepted by the network when agreed upon by multiple peers on the network with a synchronized block chain. Both Pools and Solo miners work exactly the same in the fact that they submit deadlines to peers based on ID and Nonce combination and validate the others work by hashing the provided combination. If the numbers match they agree that it is acceptable, once the lowest time that is agreed upon by peers is reached we have a new block generated.

    Pools have one additional step that solo miners don't and that is the aggregation of data of all miners on the pool. It is a little bit more over head but pools manage this by setting "acceptable deadlines". This prevents pools from being hammered by tons of deadlines that don't have a snowballs chance of winning. Additionally we are starting to see new pool code emerge that is more efficient from both Lexi and Jack that address issues of wallets not talking to peers or redundant wallet scenarios, I have even heard rumors of a "pool of wallets" theory that sounds pretty good.

    Hope this helps,

    -IceBurst



  • @IceBurst I think there are at least 2 issues here. First is the one that rds has raised which is that you get a "Deadline not Confirmed" response from the Pool. That is the one that I commented on above and which I feel could be eliminated by a retry function in the Miner code.

    The second is the one that you are referring to, which is that a deadline is accepted and Confirmed by the Pool but for some reason is not propagated / accepted by the network. This is of course only noticed when it would have been a winning block.

    I have seen this recently when I had a 6 second deadline accepted and confirmed by the pool, which then credited me with the block. However some minutes later it was the credited to someone else who had a 6 Minute deadline. Probably more difficult to fix, discussion here.

    @RichBC said in Block Winner 310908:

    Rich



  • @RichBC, yes I read your account of the 6 second DL. That scenario is even more frustrating than the one I asked about. I felt if the miner program saw a not confirmed it could resubmit after a set period of time. Didn't know if that was something that could be switched on using miner.conf parameters. Evidently not as you suggested you had asked @Blago about it earlier. Maybe a future enhancement.



  • @rds Am quite certain that a change to the code will fix the "Not Confirmed" problem as when I have seen it and restarted the miner it always results in a confirmation. The other issue and is above my paygrade and I suspect cannot be fixed by anything in the user miner code as the Pool has confirmed and thinks it has done it's stuff.

    Could perhaps be fixed by something simple in the pool code that for the best deadline(s) it resubmits the data to the network?

    Rich