hosted mining is that you can buy some TB from Burstcoin.news to get some BURST continual (like GHS in c-cex at the past). But currently i working on the Exchange...

Can someone please sort ninja, we are stuck forked since Block: 27765 everyone else on Block: 277687.

If you look at.

https://monitor.burst-team.us/

It's easy to see any Pool that is stuck forked, can this information not be used to send an email alert people and get these problems solved more quickly?

Thanks

Rich

The point I am making is that I can see ninja is forked, you can see ninja is forked and the Burstcoin network Monitor can see it's Forked, so surely it could raise an alert, even if there are a few false alarms?

Why is noone else concerned about these Forks? I switched to http://burstpool.ddns.net/ for about a Week but that also Forked and has been down for some time now, although I see it has just come back up. This is not just a ninja problem it's a general problem and the solution is not for me to say nothing or for people to switch to a Pool based on different software.


Rich

@tross Please understand I appreciate the effort that you and others who are running pools are putting in for small rewards. What I do not understand is why there are objections to me pointing out when pools are Stuck or Forked particularly when it has been obvious for some Hours that something is wrong?

It is now over 2 months since Forking became a significant issue on the network and yes I appreciate that on occasions it costs the Pool Owner money and if it was an easy problem to solve then it would have been fixed......

Bottom line is it can happen to any Pool not just the ninja based ones. As well as the Pool owners it costs Miners money as well. If I look at daily earnings days when a pool has gone Down or Forked are very obvious. It does not put Burst in a good light if at it's current size a problem like this can take this long to solve, what hope have we if there were 10 x the number of Pools and Miners?

I do not think the solution, as people are fond of suggesting, is for Miners to spread themselves evenly across the Pools or for them to use non ninja based Pools. I for one prefer the ninja pools. The Display with the wealth of information it provides and the clarity there is as to your Historic and Current Round Share. It was in fact one of the things that first attracted me to Burst.

So to those that it may concern. Please stop moaning at me when after some Hours of waiting I point out a Pool is Forked. Please stop telling me to use non ninja Pools, and yes I would go Solo except that I sometimes go 3 Days without finding a Block, and that's not a lot of fun. Finally please keep us informed as to current thinking on what the issue is, what is being tried, and what progress is being made? Transparency and information even if it's bad news is always better than being kept in the dark.

Thanks


Rich

https://intelledger.github.io/introduction.html

A description of Intel's Sawtooth Lake which uses "Proof of Elapsed Time".  I'm curious how this correlates with the PoC protocol Burst uses.

So you are saying that you consider the level of Forking and consequent downtime of the pools to be acceptable and that we have no right to ask what is going on or what the progress is being made on a solution?

On the data available on ninja pools relative to the other flavour of Pools then yes I like the coloured pies. I like that the Miners names are shown. I like that you can quickly see who has won the recent Blocks on and off the pool. I like that the Current Round and Historic Shares data is clear and easily understandable and that it represents the Payout that you will receive as opposed to an unclear and typically large number that bears no resemblance to what you will receive. I like it that the Historic Share is based on the last 50 Rounds and not thrown away after every payout or after 100 non paying rounds.

Maybe the above is unimportant to others, but I like it. 

Rich

I am also here to mine as much Burst for the least cost possible. So clarity of the payments is important to me as is being on a reliable pool and having sufficient mining power on that pool that there can be regular payments.

I agree that the pretty colours and names are unimportant to the returns, however they do no harm and add some colour to what is otherwise a boring and bland process. I still feel the other data that is available on ninja is very informative as to what your reward will be and how the Pool is doing relative to others.

I have taken a look at burstpowernetwork.ml and I only see 2 Mners and very little money being paid out, so it may or may not be robust, but it is not  being stressed and is currently way too small to offer and benefit over solo mining.

Rich

Ya, seems the dev v2 pool is also stuck/forked... Is pool software the root cause?  Or does this forking issue lie within the Burst protocol?  I would think developing/updating "new pool software" as a work-around for a deeper issue is the wrong approach to take here, especially since most pool miners would then be incentivised to mine on said pool, which doesn't help at all with decentralization.

IIRC it has something to do with the way the multithreaded wallet handles the db.

Also @includebeer - we are currently unable to figure out the 'root cause' of the issues, but they lie within the wallet. Interestingly, they seem to not happen unless there's a miner or a bunch pointed at the wallets.

We resolved the fork issue with a use of the older burst.jar from 1.2.3 version. These are temp fixes until we can re-make the error for the devs and have them fix the actual issue.

The new pool software will be available to everyone, so the issue with decentralization is a non-issue.

The pool software is to alleviate the load on the wallets so that the issue doesn't rear its head in production environment, while at the same time we resolve the actual issue.

So far, the devs haven't been able to recreate the problem since it only seems to happen on pool wallets. We're open to any ideas from anyone as far as what the 'real issue' could be.

As far as i'm concerned it has to have something to do with the multithreading that was added to the wallet, as it only started doing it after that. But since it is seemingly random, and we're not able to reproduce it on a testnet, we're setting up some workarounds for now, while we investigate the issue further.

I personally don't think there's an issue with the way we're going about it whatsoever.