Author

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

hero member
Activity: 938
Merit: 1000
11 Days without a block with 9TB - what is going on with this thing? Was finding a block every day or two at most for the last 50 days until the 8th of October. Everything running as it should.

There's a spot of bad luck and then there's this.

9TB is not enough to solo mine IMO. Why don't you come join us at mine.burstcoin.info? I'm still doing my giveaway of 1600 burst for new miners.

9TB is and has been plenty for a block every couple of days/3 days max. Why is it suddenly not happening now? Has anything changed since the 9th of October that could stop the java miner from working as it should?

Same here with 60TB. Doesn't find block since 2 days. Before that it worked great. No idea what happens then.
member
Activity: 108
Merit: 10
I don't think Java miner is having any problem, I'm on pool but it works great (shouldn't be that different)
Maybe a big bad luck timeframe?
member
Activity: 112
Merit: 10
11 Days without a block with 9TB - what is going on with this thing? Was finding a block every day or two at most for the last 50 days until the 8th of October. Everything running as it should.

There's a spot of bad luck and then there's this.

9TB is not enough to solo mine IMO. Why don't you come join us at mine.burstcoin.info? I'm still doing my giveaway of 1600 burst for new miners.

9TB is and has been plenty for a block every couple of days/3 days max. Why is it suddenly not happening now? Has anything changed since the 9th of October that could stop the java miner from working as it should?
legendary
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
11 Days without a block with 9TB - what is going on with this thing? Was finding a block every day or two at most for the last 50 days until the 8th of October. Everything running as it should.

There's a spot of bad luck and then there's this.

9TB is not enough to solo mine IMO. Why don't you come join us at mine.burstcoin.info? I'm still doing my giveaway of 1600 burst for new miners.
member
Activity: 112
Merit: 10
11 Days without a block with 9TB - what is going on with this thing? Was finding a block every day or two at most for the last 50 days until the 8th of October. Everything running as it should.

There's a spot of bad luck and then there's this.
sr. member
Activity: 280
Merit: 250
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.

The flowchart is missing the caching and retrieving from disk parts. Since the account id and nonces are run through the repeat hashing step before any network state is used, the results of the repeat hashing can be saved and reused every block, with the miner only having to do the repeat hashing once ever per nonce. This makes it so the computational expense of that initial repeat hashing can be increased any amount without causing miners to do any extra work after the initial caching process. The more expensive that repeat hashing step becomes, the more efficient using pre-cached work is over computing everything on the fly.
sr. member
Activity: 462
Merit: 250
Yes, you can do the same thing with scrypt...

The key part you may be missing in the "shoddily made flow chart" is that it "Does not include caching plot\[s\] to disk and retrieving them."  For $130 plus plotting and optimization time, a 4TB drive can store about 4*(10**12)/(2**18) = 15,258,789 precalculated values corresponding to the boxes in the bottom right-hand corner of the diagram (i.e., "Hash, then hash with the resulting hash, etc.")  The other hashes in the mining calculation are fast or only computed once per block, so you can check these 15M values as fast as you can read them off the disk.

Even the latest bitcoin mining hardware provides at best 5 orders of magnitude speedup over CPU hashing speeds, so your custom ASIC burning hundreds of watts might just about come within an order of magnitude of the speed achieved with cheap commodity hardware burning less than 10 watts (see figures 11-13).

A custom ASIC for shabal hashes would be super useful for the initial plotting, though.
hero member
Activity: 518
Merit: 500
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.

It's possible to do RAMDisk, but that's not a very cost effective way of mining. You would need a bunch of TB worth of RAM to mining with as oppose to cheaply doing it with HDDs. You try it out and give the results if it is worth it.
Yes, you can do the same thing with scrypt...

I didn't say it wasn't possible or not, I was just pointing out that it would not be cost effective. This algo proof of work is done via capacity, the larger the plot, the more efficient the deadline results are. When it comes down to it, all aglo's use storage/memory of some sort of form, may it be System RAM, SSD, HDD, VRAM and/or temporary usage of cpu cache.
legendary
Activity: 2576
Merit: 1186
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.

It's possible to do RAMDisk, but that's not a very cost effective way of mining. You would need a bunch of TB worth of RAM to mining with as oppose to cheaply doing it with HDDs. You try it out and give the results if it is worth it.
Yes, you can do the same thing with scrypt...
hero member
Activity: 518
Merit: 500
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.

It's possible to do RAMDisk, but that's not a very cost effective way of mining. You would need a bunch of TB worth of RAM to mining with as oppose to cheaply doing it with HDDs. You try it out and give the results if it is worth it.
legendary
Activity: 2576
Merit: 1186
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
It doesn't have to be a HD, it could just as well be (a lot of) RAM.
This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.
newbie
Activity: 27
Merit: 0
Can we get a mac wallet?? I'd like to get in on this and try the HDD mining, but I gotta have the OSX applications!

Just use linux version and run from terminal. I tired it on mac and it s working
hero member
Activity: 518
Merit: 500
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?

This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
legendary
Activity: 2576
Merit: 1186
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements.
It is probably just as weak to ASICs, though I can't say for sure without more information.
Do actual specifications exist for the algorithm?
Also, is anyone interested in doing a BFGMiner port I can merge?
sr. member
Activity: 462
Merit: 250
You people STILL waiting fore a miracle on this crapcoin?  LAWL.  I've moved on.  My 10931 coins are still for sale at 800 satoshis each.

There's still 10000 bursts for you, if you can talk the price down to 50s by next week.
full member
Activity: 210
Merit: 100
You people STILL waiting fore a miracle on this crapcoin?  LAWL.  I've moved on.  My 10931 coins are still for sale at 800 satoshis each.

We are waiting for the miracle that you actually really move on and not just talk about it since weeks Wink 
legendary
Activity: 1512
Merit: 1000
quarkchain.io
You people STILL waiting fore a miracle on this crapcoin?  LAWL.  I've moved on.  My 10931 coins are still for sale at 800 satoshis each.

're still waiting for the miracle that someone will buy your coins at 800 sat?

I'm diging more than 12000 burst daily with almost none power cost..
So I suggest you buy some ASSET with your 10931 Bursts instead of hating the coin...
yuk
full member
Activity: 224
Merit: 100
You people STILL waiting fore a miracle on this crapcoin?  LAWL.  I've moved on.  My 10931 coins are still for sale at 800 satoshis each.

're still waiting for the miracle that someone will buy your coins at 800 sat?
hero member
Activity: 955
Merit: 1004
You people STILL waiting fore a miracle on this crapcoin?  LAWL.  I've moved on.  My 10931 coins are still for sale at 800 satoshis each.
newbie
Activity: 20
Merit: 0
Hello!

I need some tips on how should I deal with a plot file...

ls -alt /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096
-rw-r--r-- 1 root root 1459742441472 Sep 20 22:19 /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096

The miner process always outputs error reading from file
e.printStackTrace() reveals to be an
java.io.EOFException
        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:421)
        at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399)
        at pocminer_pool.ScoopReader.readFile(ScoopReader.java:35)
        ................

while f.readFully(chunk);
chunk (rs.staggeramt * MiningPlot.SCOOP_SIZE) is 262144 bytes = 256 kb

This plot's size in bytes is 1459742441472, thus 1459742441472 / 262144 = 5568475.5 (does not divide fully), so the java.io.EOFException is totally legit.
5578752 plots * 256kb = 1462436364288, but my plot actually is 2693922816 bytes short. Maybe the plotter process got killed, or got bad I/O,and never got to write the full file.

I'm thinking about deleting the last 131072 bytes from the file. Do I also need to rename the plot to XXXXXXXXXXXXXXXXXXXX_9498624_5568475_4096 (changed the nr of nounces to reflect new size) ?




Yes, it reads based on what it sees in the filename, and your numbers look correct. If you don't care about the tiny waste in space, you can also just do the rename without deleting the extra bytes, or you can just leave it alone since it will still use all the chunks it can read.

Thank you so much. I know now what to do in the future with incomplete plot files!
Great work, dev!
Jump to: