Block Winner 310908



  • OK I know there have been numerous posts questioning Block Winners in the past and to be honest the explanation of the Timngs / reasons etc is never entirely satisfactory.

    So here's my one. A few Blocks ago I saw that I had a 6 second deadline and not surprisingly won the Block.

    0_1482939308150_jminer-310908.jpg

    Came back a while later and saw that I was no longer shown as the Block Winner and someone else also with a 6 Second deadline had won it.

    0_1482938577981_ninja.jpg

    Oh that's bad luck I thought unusual to not be the Winner with 6 seconds, so had a look to see what the Deadline was on Block 310908?

    0_1482938600603_Block.jpg

    Now in the past thing in this sort of situation timings are usually close however Deadline is shown as 6.4 Minutes as opposed to my 6 Seconds.

    So what's going on here?

    Rich


  • admin

    @RichBC Thanks for info, i saw this behavior multiple times on my own mining.
    I mentioned it e.g. here https://forums.burst-team.us/topic/2860/something-i-miss-in-wallet-version-1-2-7/10
    Finding/having best deadline is just half of the game, it needs to be propagated to network.
    If you pool-mine, you do not broadcast your result, you just send it to pool and the pool is responsible ... guess depending on 'bad' peers the pool is connected to, or due heavy load/disconnect your result has not reached the network. It also may be kind of a attack with nodes blocking/not propagating under conditions. I also run into this issue while solo-mining, guess maintaining the wallet settings could be a benefit (peers/number of connections/etc.)

    The only way to ensure a result has reached the network, is to validate it, and do a recommit to another bunch of nodes, if not. But as far as i know, no pool or miner (for solo) has implemented such a feature.
    (Commit result, and check after e.g. 1-2 sec. if a set of validation nodes received it.)

    Meanwhile, all of us, even if pool mining, should run burst nodes! Keep your wallets running! We do not want pools=network 🙂



  • @luxe i would gladly implement such a feature as this happens more often than most. had it today on my pool where we got the exact same deadline as burst.ninja. ive got a feeling however the reason why ninja wipes the floor with the rest is because its hosted on a single ip network with 4 more nodes. meaning its guaranteed to always reach a consensus before any other wallet.

    to implement such a retry feature i think its dependent more on the wallet than the pool though as it doesnt seem like theres an api call in burst that can be used in this way.

    and with the nodes idea. thats the best thing that we could do. i deliberately left the node on my old pool up for this purpose


  • admin

    @Lexicon Wallet API has just the 'submitNonce' method, not sure if it will 'recommit' if you call it 2 times on same deadline ... if not, a 2nd wallet instance with different peers needs to be used for example.


  • admin

    @Lexicon Ninja is not on the same subnet as the other Ninja style pools. Ninja is in Las Vegas, the ones I host are in Wisconsin.



  • @luxe would be ideal if the submitNonce method returned something that told you if it was propagated. the second wallet trick would work but it would also mean doubling the submitNonce API call for each miner that hits a better deadline that the last. but i guess this also means the second and third time doesnt increase stress on the local wallet but rather whoever elses i point it at lol

    anyway. in for a penny in for a pound i guess. ill write this feature into the pool today and see how it goes :). i could technically use my old pool wallet to try this. and maybe also add a third



  • @haitch cheers for clearing that up lol. only as good as the information you are given ;).


  • admin

    @Lexicon Nice, give us some feedback if it seams to work for you ... ensure you write a log every time you need a recommit 🙂 Would be a awesome promotion for your pool if you have such a feature working.



  • @luxe adds to the already nice list of features i guess 🙂 im gonna log to console the results of submit nonce to see whats returned. if something that flags up as its not commited i should then be able to log every time i need to recommit however im unsure if this functionality currently exists. and if it doesn't. it would be a damn good idea to include it.

    otherwise im just going to make it send twice by default. as its only a http api call doing this over network would result in a minuscule impact as the pool only submits the best nonce a user has anyway.

    if the first method works luxe it might be an idea to build an API in the pool code ive written that looks up other pools and uses each other as nodes. sort of a decentralized network of pools working for a decentralized blockchain. but im probably a long way off gettings something like that done. basics first and all lol



  • This is great stuff keep up the good work all.



  • ok. added the log to console submit nonce returns

    { result: 'success',
      requestProcessingTime: 172,
      deadline: 117258 }
    

    im unsure if it displays anything other than success. could be worth me recording the results for a day or so in sql server.

    i would do it to file but the amount of times this executes could result in trying to write to a locked file etc.



  • another message ive seen is

    { result: 'Passphrase does not match reward recipient',
      requestProcessingTime: 0 }
    

    that result boggles me a bit. shouldnt that say reward recipient does not match. or address does not match reward recipient.

    someone was clearly up all night 😃



  • When solo mining, if you get a green font "DL confirmed" message does that mean the network has received the DL?



  • So just briefly returning to my OP.... I can understand that it is possible that a 6 second deadline can be sent to a Pool and confirmed, but fail to make it's way into the network.

    However what I find odd is the coincidence that the Winning deadline was later reported by the Pool as 6 Seconds but when checking the the Deadline in Block Explorer it is reported as being 6.4 Minutes?

    I just happened to see this one, but does anyone have any idea how often this sort of thing happens? Makes me tempted to run 2 instances of the Miner so that all deadlines are submitted twice?

    Rich


  • admin

    @RichBC This is speculation on my part - don't know if it's actually correct. The pool probably thought it won on your block - moved onto the next one. The actual block continued mining to the 6.4 minutes, and that propagated. When the pool realized it didn't actually win the block, it put the correct winner, but your time.

    @Lexicon there is work being done for the next version of the wallet to allow better control over who the wallet peers with - so making a peerlist of pools will be possible.



  • @haitch Sound likely. I actually saw it report me as the winner, but then went away and came back some Blocks later and was surprised to see I was no longer the winner.



  • 0_1482969303141_Unbenannt1.PNG

    0_1482969318982_Unbenannt2.PNG

    Rich it happen to my pool almost everyday! But like I said someone is working for a fix!



  • @tross I have one instance in my pool where the pool says someone wins for NEWS POOL but in fact it was another one who actually won. The sad part is, NEWS Pool paid our miner the burst. I don't know if it will be ever given back to the pool. Luckily, I found it out right away and sent Burst to the pool to avoid negative balance. 😞



  • @jervis, that happens a lot when a pool's wallet sticks. Not sure how they reconcile the payout mistakes. Unless the admin for the pool sees the stuck wallet, every consecutive block is mistakenly won my one of the pool miners. If they post low DLs, before you know it the pool has paid distributions with 4 confirmations, then it's a done deal. Maybe they ask for refunds or back calculate and withhold from subsequent payouts. Messy.



  • This post is deleted!