[ANN] [BURST] Burst Mining System - A new miner for BurstCoin

[mrpsion]

I don't know what is wrong or where. I had it left mining this morning and 4-5 hpurs later checked the pool. There were no shares submitted. The miner said it submitted shares, But I had nothing. Lost 3-4k coins with this already

Which pool are you using uray/official? and which release of the miner? I have only really tested on Urays pool.  And versions prior to 1.11 would probably have had this issue.

I was using 1.11 on official v2 pool

What was your startup command?

FYI: I have just pointed all my plots at the official pool with my client, so as I can see what's up.

I just had my first share submitted.  And it showed up in the shares list on the pool.

I am guessing you have registered your account and it appears in the allowed users list?

Try with the latest release, I'll also be adding a new release tonight with some other enhancements, which will be the same code I just validated here. So you could wait for that if you want.

I have just put up release 1.20 on github https://github.com/mrpsion/burst-mining-system/releases   This is the code base I used to test, and validate that shares (well 1 share so far) were accepted on the official v2 pool.

[mrpsion]

note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round.

^from http://burst-pool.cryptoport.io/howitwork.html
Um just to let you know when using http://burst-pool.cryptoport.io/ you will be penalized for using this client as it spams lots of high deadline submits which I have noticed from looking at my score decrease on the site pretty quickly
 
Miner looks great and stats and feedback is really cool but this needs to be fixed, also if you could make a window in the gui that contains the logs that runs through the command line that would be stellar
Also if you put a donation address in your sig and make mentioned fixes and changes I am sure plenty of happy miners would be willing to contribute

Release 1.20 has log tailing built in now. You can tail the logs for any of the miners from the master node, and each miner can tail its own.

[theprofileth]

If you try to view the logs in the web gui it then causes some kind of error and stops mining for a bit in the command line and the gui
It then restarts and the number of shares and times mined resets...

[theprofileth]

Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?

[mrpsion]

Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?

Which pool?  For Urays pool, the number of shares submitted for a plot is irrelevant.  It progressively scans for better shares across all the plots only submitting one if it finds one better than the previous one.  Ideally the miner would only submit one share for the entire miner per block, but as a new block could be detected before we have finished scanning all the plots we want to submit the best shares as we find them so we get credit.

For the official pool, yes you would expect to find more shares for a large plot than a small one, but a large plot has more of a chance to get interrupted than a small one, especially if the large plot is towards the end of the list of scanned plots.  For instance on one of my miners 1 have 11 90gb plots... The last 2 plots get interrupted all the time, which means they are not completely scanned all the time, and so would produce less shares than the ones that are always scanned.

I don think there is a bug here, but I'll keep an eye out on my miners and see if I see any pattern.

Do you have a screen shot of the "system" view showing the plots and stats? I would be interested to see it.  You could pm the image if you don't want to have it out in public.

[mrpsion]

If you try to view the logs in the web gui it then causes some kind of error and stops mining for a bit in the command line and the gui
It then restarts and the number of shares and times mined resets...

I know there is an exception throw when you navigate away from the log, which doesn't harm anything as far as I can see, but I need to handle the websocket session termination better.  I haven't seen any errors when actually viewing the log.. Or any disruption in stats, but I'll play around and see if I can replicate.

Could you provide the error message and stack trace that you are seeing.

[twig123]

Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?

Which pool?  For Urays pool, the number of shares submitted for a plot is irrelevant.  It progressively scans for better shares across all the plots only submitting one if it finds one better than the previous one.  Ideally the miner would only submit one share for the entire miner per block, but as a new block could be detected before we have finished scanning all the plots we want to submit the best shares as we find them so we get credit.

For the official pool, yes you would expect to find more shares for a large plot than a small one, but a large plot has more of a chance to get interrupted than a small one, especially if the large plot is towards the end of the list of scanned plots.  For instance on one of my miners 1 have 11 90gb plots... The last 2 plots get interrupted all the time, which means they are not completely scanned all the time, and so would produce less shares than the ones that are always scanned.

I don think there is a bug here, but I'll keep an eye out on my miners and see if I see any pattern.

Do you have a screen shot of the "system" view showing the plots and stats? I would be interested to see it.  You could pm the image if you don't want to have it out in public.

What does the plot getting "interrupted" mean? and how would one prevent it?

[mrpsion]

Also for some reason my larger plot (which is about 3 times larger) produces 1/2 the shares of the smaller plot which makes no sense at least conventionally
Is this a bug or can you explain this?

Which pool?  For Urays pool, the number of shares submitted for a plot is irrelevant.  It progressively scans for better shares across all the plots only submitting one if it finds one better than the previous one.  Ideally the miner would only submit one share for the entire miner per block, but as a new block could be detected before we have finished scanning all the plots we want to submit the best shares as we find them so we get credit.

For the official pool, yes you would expect to find more shares for a large plot than a small one, but a large plot has more of a chance to get interrupted than a small one, especially if the large plot is towards the end of the list of scanned plots.  For instance on one of my miners 1 have 11 90gb plots... The last 2 plots get interrupted all the time, which means they are not completely scanned all the time, and so would produce less shares than the ones that are always scanned.

I don think there is a bug here, but I'll keep an eye out on my miners and see if I see any pattern.

Do you have a screen shot of the "system" view showing the plots and stats? I would be interested to see it.  You could pm the image if you don't want to have it out in public.

What does the plot getting "interrupted" mean? and how would one prevent it?

A plot is interrupted if a new block is announced on the network before the plot has finished being scanned.  There is no point in continuing as any shares we would have created from then on would have been for an old block and so would be invalid.

Some times you can't prevent it... For instance when a block is found 10 seconds after the last one.... You are pretty much certain to get interrupted... But you can minimize your chances mainly through drive speed.

[gigica viteazu`]

i`ll love to have this working for solo mining

[mrpsion]

i`ll love to have this working for solo mining

Ill work on this tomorrow... well today... its past midnight.

[Elokane]

So how many coins per day can one get with 1TB currently?

[mrpsion]

So how many coins per day can one get with 1TB currently?

About 1000

There is a little tool out there that calculates this... somehow

https://bchain.info/BURST/tools/calculator

[PeaMine]

Is there a way to set something on the remote miners running this to report back to the master miner that oversees them all?
Finding exactly what IP each one actually finds to can be troublesome, but I'm being picky/lazy.

[theprofileth]

BTW how is the uray deadline limiting handled cause from my brief look over at the github it looks like you cant submit things that are lower than your lowest deadline submitted, which while fair from a pool manager perspective the vast majority of other miners are submitting lots of low deadlines that aren't necessarily all lower than their current lowest but regardless of this it positively affects their score. Point being that you should either just slowly scale the threshold or simply use the algo provided by the site to calculate if the share should be uploaded

deadline value from miner is converted into share value using this equation
share = 1000 / ( NetDiff * Deadline + 1 ) 0.75
where NetDiff (network difficulty) is calculated by Block0-BaseTarget / Block#N-BaseTarget

note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round.

IE if your value isn't greater than 0.001 it definetly shouldnt be uploaded but something more reasonable would be to simply assume the -0.001 is in effect and not allow shares that would be worth less than 0.01 safely preventing scores from being lowered and slowly increasing the necessary deadline as needed 

[mrpsion]

BTW how is the uray deadline limiting handled cause from my brief look over at the github it looks like you cant submit things that are lower than your lowest deadline submitted, which while fair from a pool manager perspective the vast majority of other miners are submitting lots of low deadlines that aren't necessarily all lower than their current lowest but regardless of this it positively affects their score. Point being that you should either just slowly scale the threshold or simply use the algo provided by the site to calculate if the share should be uploaded

deadline value from miner is converted into share value using this equation
share = 1000 / ( NetDiff * Deadline + 1 ) 0.75
where NetDiff (network difficulty) is calculated by Block0-BaseTarget / Block#N-BaseTarget

note : to prevent user spamming low share, we implement share penalty of -0.001 on each submission for miners who submit nonce that has higher deadline than their (current round) own best deadline, as spamming low share is no use since pool will always pick one best deadline for every submitted nonce per round.

IE if your value isn't greater than 0.001 it definetly shouldnt be uploaded but something more reasonable would be to simply assume the -0.001 is in effect and not allow shares that would be worth less than 0.01 safely preventing scores from being lowered and slowly increasing the necessary deadline as needed 

on urays pool according to Uray, who i pm'd on something similar, only your best share is actually used.  the penalty is to stop people trying exactly what you suggest, just to try and preserve system resources on the pool.

So if you first submit a deadline of 1000000, that's what you will get credit for initially, however if you then submit 10000 you will instead get credit for that one and so on... its not cumulative.  If then after the 10000 you submitted 10001 you would get a penalty for this.   So if you have multiple miners you will get some penalties as the miners don't know about the other shares the other miners have submitted, but it would be minimal, and you would just get credit for the best share submitted across all of your miners that use the same address.

[mrpsion]

Is there a way to set something on the remote miners running this to report back to the master miner that oversees them all?
Finding exactly what IP each one actually finds to can be troublesome, but I'm being picky/lazy.

I could, and I was thinking about something like this, but I too was lazy when trying to roll out the miner .  The question I have for the group is what style of auto discovery would we want?  i.e. do most people run their miners on networks that have multicast enabled across all the switches and hubs etc? or would we just want to instead of listing all the nodes on the masters start-up command, just list the master node on every other nodes start-up command?

[PeaMine]

Is there a way to set something on the remote miners running this to report back to the master miner that oversees them all?
Finding exactly what IP each one actually finds to can be troublesome, but I'm being picky/lazy.

I could, and I was thinking about something like this, but I too was lazy when trying to roll out the miner .  The question I have for the group is what style of auto discovery would we want?  i.e. do most people run their miners on networks that have multicast enabled across all the switches and hubs etc? or would we just want to instead of listing all the nodes on the masters start-up command, just list the master node on every other nodes start-up command?

Perhaps a config file or command line argument on each remote node that would cause it to connect to a certain master node.
Same way it currently works where the master lists each remote node, but reversed each remote node lists the master it connects to.

[zakorus]

what arguments do i use to start this up?

[dmz241]

I am new to this. I am really confused. I downloaded the gui miner on windows how do I run it now? I do have the jvm installed.

[mrpsion]

what arguments do i use to start this up?

Take a look at the readme on github, https://github.com/mrpsion/burst-mining-system. but basically its just

java -jar mining-system-1.20.jar --pool.url=http://{pool.hostname}:{pool.port} --plot.generation.threads=2

or something similar