How does a higher DL win a block??



  • Block 324382, how did DL 3 min, 57 sec beat 3 min, 53 sec?

    0_1486189630672_upload-12accd0d-c192-446c-82ca-aa8d913593ed



  • may not be displayed correctly , check other pool's to see what info they have displayed. also i think its possible for the person with the 3 min 57 sec DL to of found and submited that dead line in 3 sec witch would bring total to 4 min block forge, and person with 3 min 53 sec dead line to of found and submited at say in 30 sec witch would give them a total of 4 min 23 sec block forge........ someone will have to clarify but i think thats how it work's



  • @Gibsalot said in How does a higher DL win a block??:

    may not be displayed correctly , check other pool's to see what info they have displayed. also i think its possible for the person with the 3 min 57 sec DL to of found and submited that dead line in 3 sec witch would bring total to 4 min block forge, and person with 3 min 53 sec dead line to of found and submited at say in 30 sec witch would give them a total of 4 min 23 sec block forge........ someone will have to clarify but i think thats how it work's

    I don't think it works like that at all. Pretty sure a DL is a DL. Also that DL on ninja was confirmed in under a minute, so it wasn't "late".

    Here is a pic from the EU pool, the first was from Ninja.

    0_1486190820541_upload-0a1ebc78-17a2-4cea-a72d-db3f941dc0a9



  • not sure then , i know i have seen pools display wrong info befor .. for instance i mine on tross pool its a lex code Uray pool there have been a few times my miner say my DL is say 5 min 30 sec .. the pool im on says 5 min 30 sec and i won that block ... but all the ninja code polls will have me listed as the winner but will show a completly dif DL time off by 20 or 30 sec's.



  • does not happen all the time and not in a long wile but i have seen it do that ... back in Dec was the last time i saw it happen



  • @Gibsalot said in How does a higher DL win a block??:

    does not happen all the time and not in a long wile but i have seen it do that ... back in Dec was the last time i saw it happen

    @Gibsalot, Thanks for weighing in, hopefully some of the developers, admins etc. could shed some light on this.



  • @rds You need to look at block Explorer where the deadline for BURST-583A-8RBH-FR93-F6C3K on Block #324382 is 3.82 Minutes = 3Mins 49.2Secs. I think this can be caused by time differences on the Different Pools, but the Blockchain decides.

    Having said that I have seen anomalies in who wins Blocks that cannot be explained.

    Rich



  • @RichBC,

    By saying, "the blockchain decides", isn't that a consensus of mining programs that have the DL values stored in their program registers?



  • @rds by saying the block chain decides ... essenly every wallet with a fully synced data base counts as a Node for the chain when a block is forged every node that had Deadlines submited to them tell the other nodes what there best DL was and the actual forger of the block is who ever 51% of the Nodes decide had the best over all deadline. its all fully automatic and when you have 2 or more deadlines vary close together somtimes dif nodes can show dif people won the same block because if can take a few min for all of the nodes to talk to each other and decide on a winer .... rule of thumb if the block was forges less than 4 block's ago info displayed may not be correct.



  • thats also why most of the pools payout for a block that was forged, 4 blocks after they "won" the block to make sure they actuly won and are not giving burst away by accident


  • admin

    @rds I saw such things earlier, in general ... the fact the the pool knows the best deadline, does not mean, that the pool was able to commit it to the rest of the network ('at all' or 'in time').
    Simple example (for 'in time') ...

    • User A has a deadline of 30sec and commits it after 10sec.
    • User B has a deadline of 20sec and commits it after 40sec.
      --> User B has better deadline, User A wins the block.

    Maybe the above timings where closer to each other and before the pool had noticed that the round is over already, the better deadline got committed.



  • @luxe Great answer! I seen this many many times. I have talked to many people about similar issue.


  • admin

    @tross Thats the 'optimistic' explanation ... i also discussed that before and had issues myself. Another szenario would be 'evil' nodes in the network with modified code, to simply not propagate deadlines under conditions. To prevent that the only solution would be, that more users run nodes instead of just using online wallets and mining without a local wallet server.



  • This is why I run a Local Wallet while mining! Mining is finding Coin but supporting the Network is running a Wallet. The more wallets the stronger the network. I also notice lag on pools. You can see how some start sooner and others are slightly delayed. Up to a few seconds and there is your time problem out in the open.



  • @CryptoNick It might be they dont run a program like dimension4 or could even be the internet itself. In my case where I run the server at home there are other variables.


  • Banned

    OK, it works like this. The pools are just a buffer and do calculations just for display, these calculations may be skewed.

    The pool then forwards the deadlines to the wallet where the calculations are done and broadcast.

    There is no way to cheat it, pool code cannot be modified to do so.



  • @Focus I woldnt bet on it anything is possible.



  • @Focus said in How does a higher DL win a block??:

    OK, it works like this. The pools are just a buffer and do calculations just for display, these calculations may be skewed.

    The pool then forwards the deadlines to the wallet where the calculations are done and broadcast.

    There is no way to cheat it, pool code cannot be modified to do so.

    Maybe I don't understand the code but if I submit a number like 233 (3 min 53 sec), why does the pool need to do a "calculation" to display 233 (3min 53 sec)? If that number is broadcast across nodes for over 3 minutes, I would assume a lot of wallets have that number stored. Then 233 seconds after the block started, a new block starts and a number higher than 233 is posted as the winner. It doesn't seem rigorous. Is there a fault in the code? Was the code tested on a testnet? Don't know, it just doesn't seem right.

    With over 100 blocks generated since bolock 324382, the report is that the 237 DL won the block. The 233 DL did not.


  • Banned

    @rds said in How does a higher DL win a block??:

    @Focus said in How does a higher DL win a block??:

    OK, it works like this. The pools are just a buffer and do calculations just for display, these calculations may be skewed.

    The pool then forwards the deadlines to the wallet where the calculations are done and broadcast.

    There is no way to cheat it, pool code cannot be modified to do so.

    Maybe I don't understand the code but if I submit a number like 233 (3 min 53 sec), why does the pool need to do a "calculation" to display 233 (3min 53 sec)? If that number is broadcast across nodes for over 3 minutes, I would assume a lot of wallets have that number stored. Then 233 seconds after the block started, a new block starts and a number higher than 233 is posted as the winner. It doesn't seem rigorous. Is there a fault in the code? Was the code tested on a testnet? Don't know, it just doesn't seem right.

    With over 100 blocks generated since bolock 324382, the report is that the 237 DL won the block. The 233 DL did not.

    Submitted nonce calculations on done in the wallet, the pool does it's calculations for display purposes only.



  • @Focus, that's my point, what calculation?? A number is a number. The lowest one should win. I don't call code that looks for the lowest number to be a calculation per se.

    My point is, the system shows flaws. If the basis for winning a block is the lowest number, and there is evidence that shows the lowest number doesn't always win, then there is a problem. This problem is validated by comments like, "yea, I see that happen every so often", @tross says, "I've seen that many, many times".

    Just because it happens, doesn't mean it's right.

    Seeing flaws like this fosters a loss of confidence. And at the end of the day, that's the only thing that insures cryptocurrency survival, is confidence that the system is not flawed.

    I guess the software is open source, and I could look at it myself, but I don't have the expertise that other here do. I'm a user of the system and I am reporting what I see as a flaw.