Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 579. (Read 2171057 times)

I have also noticed this for past 24-48 hours (not as long as 6 days !)
There are many accounts getting paid with large amount even though they are not constantly submitting high shares (low deadlines)
e.g.



How could they get such a large payouts with those scattered pattern of low shares in between ?

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

Hello
There have been changes on the SG Uray pool?
My payments have never been as bad as the last 6 days, even when I had less hdd.
I win 3 times less than the number of blocks I find.
The diff has not yet increased.
I am the only one to notice a decrease in performance?

If you have 4 hd connected to one pc, is it better to run 1 miner for all 4 hd or 4 different ones, one for each drive?

Thanks!

With some versions of gpu mining , the miner and pool negotiate (or rather, the pool instructs the miner) what is considered a deadline worthy of consideration. So a really slow miner will be allowed to send small deadlines, while a really fast miner will have a higher threshold reg. what to send.

This should result in a reduced traffic, but still enough samples to figure what the power of the miner is.

Given the custom deadline limit sent to the miner, and the nonces returned, the pool should be able to figre an estimate as to how much plot file has been plotted, and thus, what share of found blocks to allocate.

for instance of one miner negotiates a minimum of 1000 and another a minimum of 10000 then you could "just" calculate each of the sub 1000 nonces you get with the same weight as the number of sub 10000 nonces that you would've gotten if you had allowed them to be transferred.

Not sure i make myself clear, but i hope this might be of inspiration for perhaps a new miner protocol down the line - you should be able to create miner and pool that is pretty much totally fair, esp if you calculate the estimated plot size over a reasonable number of blocks.

If things are dynamic enough the pool could even hike the proof-of-work difficulty to reduce traffic, and just compensate in the calculations. So you could have the pool run at a relatively stable traffic burden.

You would of course have to code both miner and pool part of such a negotiation protocol, but pehaps you can be very much inspired by scrypt pool source.

All profits to ByteEnterprises, so grab urs now!!!
https://burstforum.com/index.php?threads/ann-byteenterprises.310/

Lolz, all this advertising

Bought 10

The disk will of course be used.. once when the plot file is created in the first place.

After that, every time there is a block, 1/4096 of the 256MB nonces that the file is made up of, is read.   So after 4096 blocks you will have read in the entire file one time (on average, what nonce is read next is random)

there are 1 block every 4 minutes, so in principle you are reading all the byes in the the plot file once every 4 * 4096 minutes

Wether that is wear and tear beyond your personal comfort zone is.. up to you to decide.

I was just wondering because the only thing I have access to atm is an SSD, and i didnt want to use that if there was a risk for it do be damaged while mining this.
In a few weeks I'll have a TB HDD to work with though

3 days till 50k + in prizes are handed out!!!

https://burstforum.com/index.php?threads/ann-bytelotto14.311/

Plus, ur ticket doesn't expire till Dec. 23!!!

Only 10 burst / ticket, so grab yours quickly!!

I'm trying to understand why with 11 TB of plot files generate just 3000-3500 BURST per day that it seems low according the BURST calculator that show me the average of 6500 bursts.

Actually I have 5 Disks connected with USB 3.0 for a total of 8 TB and 2 nfs NAS share for a total of 3TB, I have a total of 63 plot files of various dimensions between 25GB to 1TB.

All this files are on 1 miner istance on a Linux server. The server is an Intel Celeron CPU with 4GB of RAM.

Is it better to create 1 miner instance for each physical disk ?

I have to change the hardware for a faster CPU and more RAM ?

Thanks

Fabrizio

Wow... Impressive... I may get into this, but at the current moment I don't have much storage space to spare....

Now it says HDD mining... Ik SSDs are similar to HDDs, but they have a finite number of writes before they fail. How well do they hold up to this? Are the plots constantly being written and rewritten?

Do the devs have any plans to adapt this to be of use? Because right now all I see is diska space being used up, but not being used.

I may get a team together, or inform the right people (I know a dev whod be interested) and see if we can adapt this to be used as a decentralized storage server. That is unless this dev team is already planning on going that way, if that's the case I'll step off.

The plots are written during the plotting process, afterwards they are only being read so there would be no wear&tear of the SSD. However, since SSDs speed doesnt really matter for burst minig it is better to use regular HDDs.

Distributed storage is on the roadmap, but far in the future. I suppose you could talk to the dev about it