sorry just messed up with dns table, and fucked up, as soon as dns entry propagate to correct values again, it will work
currently pool.burstcoin.io pointing to 104.28.22.80 while it should be 23.227.167.164
cloudflare just taking over that domain which they shouldn't

that is what currently implemented, averaging on sliding window, but big miners complain that when they found a block they still get regular payout, so i create SG pool that reward them most, by rewarding more on recent score, and smaller sliding window, just more like solo mining

but yeah I admit the most fair calculation statistically would be like dev-pool, summed up all submitted nonce that within deadline limit

sometime anomaly like this could happen on fast block, while the large miners are still reading their plot, small miner already submitted their good deadline, and then new block come, large miners too late to submit their nonce

or it could be their past failed payout are accumulated into balance, and when pool has funds, its going up to the queue for payout

but i don't know... I admit it could be bug too... i will check for it

just FYI, pool does not really suffer from network traffic, pool suffer on verfiying computation, every single nonce miner send, pool will need to do shabal256 hash ~48000 times, that is for single nonce from one miner, on one round on average there are 1500 nonces received for 100 miners

i believe you are talking about stratum protocol (by saying scrypt source), stratum was aimed to reduce traffic by adjusting pool-diff and to make miner can create his own job without need to ask pool regularly, its completely different to burst, while on PoW the more nonce you send the more reward you get, and also PoW algorithm was made to be hard to calculate and very easy to check for its validity

on burst does not like that, on burst you just need very small network traffic no matter how large your plot is, and burst mining does not really use cpu power, miner just need to do 1 shabal256 hash per nonce they have, but to verify the validity of deadline will need 48000 more power

yeah I understand your point, to make it simple : (accountId+NonceNum) == ActualNonce, so statistically for (1 + 1000) which is single account with large nonce would be equal to (1000+1) which is 1000 accounts with small nonce, so it would be better to choose (1000+1) since 1000 account with bad deadline (which no problem because of no deadline limit) would be added up into cumulative reward.

but the actual calculation does not end up there, there are some "distribution window" which is when pool found a block, the reward is distributed into past-blocks allocation and future-blocks allocation, what I am trying to do with this is, to get some "averaging" so that if you have large variance on deadline you still get low reward because on average your scores still bad, but if your variance is good (which is low) the reward is high.

now if we try to use 1000 accounts with small plots, all those 1000 accounts will have high variance on deadlines, and what i am to achieve with curve is, if we summed up all of those 1000 accounts reward it would be less or equal than 1 account with low variance

i know its complicated and i can't really proof it if it works, i am open for suggestion if anyone have better idea, the point i want to achieve is :

if possible we shouldn't need deadline limit, because we are using pool to reduce variance, no matter how small your plot, you want to get stable earning, even if its very small, if we have deadline limit the payout will be irregular because in most of the blocks your deadline will be higher than limit and it does not counted

and then if we does not use deadline limit, miners can just send all nonce they have and pool would be dead to verify all of those nonces, so we do need deadline limit (which what dev-pool did) or we just say it each account can only send one of their best nonce (which what my pool did)

and then we have a problem again, what happen if miners would just create a lot of account with small plot for each of those account, so each of the account can send its best nonce, by doing this they can summed up their total earning.

up to now, my solution is to use averaging, you are rewarded by your average best nonces up to 100 blocks, by doing this miner would only need to send one of their best nonce per block which will reduce computation on pool and (should) reduce traffic, and also very small capacity miners still be counted up every block for any deadline they have



illustration of what i am trying to achieve, total reward of 5 accounts still be lower than single account because single account would have better average best deadline

you might be correct, and also note that reward does not linear to the best deadline submitted on my system, and also reward distribution is "skewed", thats why it has different curve between US, EU and SG each of them tuned to favor different type of miners capacity.

on SG pool you might be get less payout if u are using 1000 accounts each of 1GB capacity instead of 1 account of 1 TB capacity, but on US pool its yet to be checked does thousands of small account result to better payout, while on EU pool you might not get payout at all by using 1000 accounts each with 1GB size

i dont see this as disadvantage for miners, because it give them options to choose pool, each pool can have unlimited different characteristic instead of just PPLNS, PPS or Prop like on conventional pool

and also you can check the result by using this API :

http://compute.burstcoin.io:8109/burst?requestType=getDeadline&accountId=YourAccountNum&nonce=5889794&height=32848&target=3941683&scoop=427&gensig=db8cbd6f3b4347af33b6c5dbd014e88886b1534c471ba4437958111360a83697

since you dont provides your accountNum, replace the "...accountId=YourAccountNum..."

this API will re-create the plot from scratch based on the information you provided (just like on OP diagram), and then return the deadline

your miner submit this :


pool reply with this :


so the result is different, when your miner say that nonce could result in 0 days deadline
after pool replot it with your submitted nocne and account id, it did not result in 0 days of deadline,
so its unconfirmed deadline

it could be because your plot is different than pool plot, some issue like this was happened because of plot optimizer or corrupted plot, and also because miner and pool check the nonce against different gensig due to different block height

i have more than 10 miners scattered around the world on my vps, mining at my own pool but never have this unconfirmed deadlime, i would love to investigate this, but i can't reproduce it, when you encounter this can you give me:
1. your accountId
2. nonce that has unconfirmed deadline and
3. scoop number and baseTarget when this problem occured (or exact block height)

cool... lets hack this address! a lot of NXT, BURST and NHZ!
writing openCL RS address bruteforcer...

its poloniex address

whats funny is they are using same passpharase for NXT, NHZ and BURST

at the same hour

the problem is you see it wrong, its BURST, not BTC

we are #1 sorted by % change(24h) on coinmarket cap



while on coingecko we are ranking #38



look our community rating is like a shit, because we dont use enough FB, Twitter, Reddit

i think i see something weird going on here on the blockchain

looking good here, which one is not responding, ur miner or pool website?

you need to increase your stagger size to get faster

yeah, its just for fun
and BURST-S37A-4WRB-RJ35-7WN5A just stole all of those funds !
omagad...

its just two letter, english ASCII letter, so it will be a..z,A..Z , two letters so there will be 52*52 combination = 2704

when you open the wallet with your guessed passphrase does the acoountId (public key) is same as the list ?
if not, then you guessed wrong