How does a higher DL win a block??
-
@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
-
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
-
@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.
-
@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.
-
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.
-
@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.
-
I was talking about when it is reported and how it makes it to the wallet. If there is a lag in display there is also a lag in reporting. When a DL is Confirmed and there are a few seconds between like the example, if the DL was found right at the end of the round it didn't make it to the wallet in time to register. The one that registered could have been found in 10 seconds. The one that was better could have been found at 3:45 and didn't have time to register.
Most likely the DL was found before 3 minutes so this is why I am saying there could be a lag in the network. The confirmation of the block on the network is the critical aspect. What miner/pool reports it to the nodes first. I don't think it happens that often to really cause concern.
-
@CryptoNick said in How does a higher DL win a block??:
...
Most likely the DL was found before 3 minutes so this is why I am saying there could be a lag in the network. The confirmation of the block on the network is the critical aspect. What miner/pool reports it to the nodes first. I don't think it happens that often to really cause concern.That 3 minute deadline was sitting there for over 2 minutes. It was not my account so I can't be sure, but I pool mine on Ninja the confirmations are almost instantaneous.
According to the comments above, it does happen often and it should be a concern. It speaks to the integrity of the Burst network.

