Bitcoin Forum
May 11, 2024, 08:53:00 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ... 118 »
981  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 08:00:21 PM
For everyone who wants to know if their plot ranges do overlap:

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

Just copy filenames (or output of "ls -l" or "dir") into the box.

(let me know if you like it!)

Nice tool. This should go on the OP.
982  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 06:53:15 PM
Quote

Wish I even had at least 2 or 3 blocks...lol.....Nearly going on 96 hours on 1.5TB with ZERO blocks....I'm going to give this til Sunday, if no blocks by then I'll give up mining until a pool is up....
I mine 50 hours with 600GB and don't have a result... Without a pool it's going to be a waste of time. I actually stop to mine at that moment.


hmm can't belive that, are you sure you login to wallet with passphrases.txt from mining folder?!
is your mining/plots folder 600GB?! sry, but we had all this before ... just want to be sure you did everything correct ...


Exactly as the direction dictate.

Quote

Wish I even had at least 2 or 3 blocks...lol.....Nearly going on 96 hours on 1.5TB with ZERO blocks....I'm going to give this til Sunday, if no blocks by then I'll give up mining until a pool is up....
I mine 50 hours with 600GB and don't have a result... Without a pool it's going to be a waste of time. I actually stop to mine at that moment.

That's not necessarily true, eventually you will find something. Just gotta hold out. The first 2 days I was mining, I hit 6 blocks before my plotting had even finished, now I have been over a day with nothing, and much more space. So, it's all about luck and whatnot, just keep going and you'll hit something. But you know if you want to stop it's not going to hurt my feelings. Will give me more of a chance to hit blocks! lol.

Your such the comedian.  Tongue

That didn't really help with you saying you hit 6 blocks in the first 2 days....I know it's luck, but damn me and few others are feeling left out until a pool is out. There must be something that gives a edge mining this that people are getting so many blocks.

Quote

Wish I even had at least 2 or 3 blocks...lol.....Nearly going on 96 hours on 1.5TB with ZERO blocks....I'm going to give this til Sunday, if no blocks by then I'll give up mining until a pool is up....

I mine 50 hours with 600GB and don't have a result... Without a pool it's going to be a waste of time. I actually stop to mine at that moment.

That's not necessarily true, eventually you will find something. Just gotta hold out. The first 2 days I was mining, I hit 6 blocks before my plotting had even finished, now I have been over a day with nothing, and much more space. So, it's all about luck and whatnot, just keep going and you'll hit something. But you know if you want to stop it's not going to hurt my feelings. Will give me more of a chance to hit blocks! lol.

it's really not going to cost you much at all to keep mining if you've finished plotting unless you need to space back from your hdd

It's nice that it's power efficient, but that's a moot point when your not getting nothing in return. I don't need any of the space, I have these drives as spares.

For use few getting nothing at the moment; It's like getting free gas to drive anywhere, but never getting to the destination(s) you want to get to.


983  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 03:21:14 PM
i have mined since start.finally finsished plotting 1.8 TB hard drive today and i have found 32 blocks

i think you're in the lead. i discovered this coin a bit late and started plotting on tuesday and still only halfway through. i have 1.2tb out of 2.4tb i want plotted and have only a hand full of blocks. i've only got one miner and wallet running on the one pc. i wonder if it makes a diff doing it your way by breaking it up across more pc?

damn, i'm at 4 TB right now with 20 blocks ...

is it correct that the deadline is only important, if nobody has found a block?! just got one with deadline >5k ... would that mean, that deadline becomes more and more unimportant with growing network capacity?!

Lowest deadline I've hit is 2504 and got no block yet. Been hovering around 10,000~150,000 most of the time. Maybe I'll just turn all the hdd's into a JBOD and redo plot creation to make one large plot to see if I get more lucky.
984  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 02:56:08 PM
thx for help, so they are useless, I should delete them, or can I rename the files and the bat's used?


kinda what I suspected.
the 800000 and 80000000?

i have mined since start.finally finsished plotting 1.8 TB hard drive today and i have found 32 blocks

can someone please advise on these plots settings on my primary pc:

1097082171119035817_0_204800_1000
1097082171119035817_1_800000_500
1097082171119035817_1_3200000_500 (still plotting after 2+ days)
1097082171119035817_1_80000000_500 (still plotting after 2+ days)

thinking I error'd in these plot settings, maybe I need to redo...?
not quite sure but it looks like u have plots over lapping

All of them are going to overlap...

One drive needs to be 0 204800
next drive 204801 1004801
next drive 1004802 4204802
and lastly 4204803 7404803

that way your plots are all for the same account #, but are all spaced out and will have the greatest possibility of generating a block...

I have personally had really good luck with the following settings...but that may just be me (around 27 blocks) and I using just over a full TB combined on 4 computers, but with 4 different wallets... (1x500Gig, 1x260Gig, 1x450Gig, 1x200Gig)

If your on windows, you could set up your run_generate files like so:

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 1097082171119035817 0 204800 1024 5

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 1097082171119035817 204801 1004801 1024 5

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 1097082171119035817 1004802 4204802 1024 5

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate 1097082171119035817 4204803 7404803 1024 5


Wish I even had at least 2 or 3 blocks...lol.....Nearly going on 96 hours on 1.5TB with ZERO blocks....I'm going to give this til Sunday, if no blocks by then I'll give up mining until a pool is up....
985  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 02:53:25 PM
If anyone is interested, the conclusion of my test to see if I could speed up plot generation by farming it out using cluster/cloud computing is:
Yes it can be done, but it is probably not worth it.  This is what I did using Amazon EC2...

First I created a single instance (2 core) to act as the server for the plot storage and also act as the wallet server / miner.
This instance had a 1TB Elastic Block Store volume attached to it (1TB is max EBS volume size on AWS). I made this volume available to the network using NFS

I then created a "plot generator" instance with much higher CPU capacity (C3.xlarge 8 core). I mounted the shared volume so it appeared like a local disk and started creating 10GB plots
I then created a few scripts so that upon startup the instance would auto-mount the NFS volume, figure out what the last used nonce range was, and start mining from the next 10GB plot
Finally, I created an image of this instance and spooled up 100 more instances like it (spot rates, nice and cheap).

To begin with it all looked great but I soon hit the bandwidth limit of the instance I was using as the server.  In essence the server didn't have enough network bandwidth to cope with all of the data being copied to it.  This restricted plot creation to a little over 100GB / hour.  Changing the instance type of the server instance to one with a "high" network performance got this up to around 400 GB/hour.  If I had have left it running I would have created all 1 TB of plots in 2.5 hours, at a cost of around $20.  This could have been repeated or even parallelized to create several 1TB volumes full of plots in a relatively short amount of time.

After all the fiddling about getting it working, I spent around $70 testing this stuff out, only to conclude it was too much hassle.  And as OP said earlier, the cost of EBS storage on AWS is too high to make this a viable long term mining option.  That said, had I have done all of this on day one, I would have scaled the process out and had 10TB+ up within the first few hours and dominated the mining.  Good to know I have the process licked for the next PoC coin Smiley

Unfortunately I STILL don't have any BURST as I don't have any spare capacity at home so haven't been able to mine at all Sad  So if anyone would like to donate some coins to offset the cost of testing all of this, my address is BURST-WADY-CBZE-HSJU-2NH5G

Many thanks!

At $70 per day, that's $2100 per month. You can nearly buy a mobo, a used 6/12 core (12/24 threads) Intel cpu, Ram and some HDD's for that price, give or take....LOL
Sorry you misunderstood - I spent $70 figuring this out. It would cost $20 to generate 1 TB in 2.5 hours (instead of a couple of days so you are mining at full pelt quicker).  Once it is generated, it would cost around $15 a month for the server and $100 a month for storage.  And at current rates that would probably still be profitable

Thanks for the breakdown, it was kind of vague on how the total came to be. That's ok, but I guess a couple days waiting for plot to be created isn't that bad and only an inconvenience. That's money that can be save towards buying more storage to mine with.
986  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 12:22:46 PM
If anyone is interested, the conclusion of my test to see if I could speed up plot generation by farming it out using cluster/cloud computing is:
Yes it can be done, but it is probably not worth it.  This is what I did using Amazon EC2...

First I created a single instance (2 core) to act as the server for the plot storage and also act as the wallet server / miner.
This instance had a 1TB Elastic Block Store volume attached to it (1TB is max EBS volume size on AWS). I made this volume available to the network using NFS

I then created a "plot generator" instance with much higher CPU capacity (C3.xlarge 8 core). I mounted the shared volume so it appeared like a local disk and started creating 10GB plots
I then created a few scripts so that upon startup the instance would auto-mount the NFS volume, figure out what the last used nonce range was, and start mining from the next 10GB plot
Finally, I created an image of this instance and spooled up 100 more instances like it (spot rates, nice and cheap).

To begin with it all looked great but I soon hit the bandwidth limit of the instance I was using as the server.  In essence the server didn't have enough network bandwidth to cope with all of the data being copied to it.  This restricted plot creation to a little over 100GB / hour.  Changing the instance type of the server instance to one with a "high" network performance got this up to around 400 GB/hour.  If I had have left it running I would have created all 1 TB of plots in 2.5 hours, at a cost of around $20.  This could have been repeated or even parallelized to create several 1TB volumes full of plots in a relatively short amount of time.

After all the fiddling about getting it working, I spent around $70 testing this stuff out, only to conclude it was too much hassle.  And as OP said earlier, the cost of EBS storage on AWS is too high to make this a viable long term mining option.  That said, had I have done all of this on day one, I would have scaled the process out and had 10TB+ up within the first few hours and dominated the mining.  Good to know I have the process licked for the next PoC coin Smiley

Unfortunately I STILL don't have any BURST as I don't have any spare capacity at home so haven't been able to mine at all Sad  So if anyone would like to donate some coins to offset the cost of testing all of this, my address is BURST-WADY-CBZE-HSJU-2NH5G

Many thanks!

thanks for sharing. sent you some for your efforts.

Thanks also paul. I would send you some, but no luck for the pass 72 hours plus mining. These guys with smaller hdd's are getting block left and right with 48 hours....

i guess that's the frustrating thing about this coin. it does seem like luck has a lot to do with it. it would be interesting to get a poll going to see what the average number of block found per miner is so far.

It is, but you get use to it when it comes to solo mining crypto-currency. Seeing people with 30GB to 80 GB hdd's finding a block to 3 blocks within 48 hours is just surreal at times....
987  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 12:02:52 PM
If anyone is interested, the conclusion of my test to see if I could speed up plot generation by farming it out using cluster/cloud computing is:
Yes it can be done, but it is probably not worth it.  This is what I did using Amazon EC2...

First I created a single instance (2 core) to act as the server for the plot storage and also act as the wallet server / miner.
This instance had a 1TB Elastic Block Store volume attached to it (1TB is max EBS volume size on AWS). I made this volume available to the network using NFS

I then created a "plot generator" instance with much higher CPU capacity (C3.xlarge 8 core). I mounted the shared volume so it appeared like a local disk and started creating 10GB plots
I then created a few scripts so that upon startup the instance would auto-mount the NFS volume, figure out what the last used nonce range was, and start mining from the next 10GB plot
Finally, I created an image of this instance and spooled up 100 more instances like it (spot rates, nice and cheap).

To begin with it all looked great but I soon hit the bandwidth limit of the instance I was using as the server.  In essence the server didn't have enough network bandwidth to cope with all of the data being copied to it.  This restricted plot creation to a little over 100GB / hour.  Changing the instance type of the server instance to one with a "high" network performance got this up to around 400 GB/hour.  If I had have left it running I would have created all 1 TB of plots in 2.5 hours, at a cost of around $20.  This could have been repeated or even parallelized to create several 1TB volumes full of plots in a relatively short amount of time.

After all the fiddling about getting it working, I spent around $70 testing this stuff out, only to conclude it was too much hassle.  And as OP said earlier, the cost of EBS storage on AWS is too high to make this a viable long term mining option.  That said, had I have done all of this on day one, I would have scaled the process out and had 10TB+ up within the first few hours and dominated the mining.  Good to know I have the process licked for the next PoC coin Smiley

Unfortunately I STILL don't have any BURST as I don't have any spare capacity at home so haven't been able to mine at all Sad  So if anyone would like to donate some coins to offset the cost of testing all of this, my address is BURST-WADY-CBZE-HSJU-2NH5G

Many thanks!

thanks for sharing. sent you some for your efforts.

Thanks also paul. I would send you some, but no luck for the pass 72 hours plus mining. These guys with smaller hdd's are getting block left and right with 48 hours....
988  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 12:00:19 PM
If anyone is interested, the conclusion of my test to see if I could speed up plot generation by farming it out using cluster/cloud computing is:
Yes it can be done, but it is probably not worth it.  This is what I did using Amazon EC2...

First I created a single instance (2 core) to act as the server for the plot storage and also act as the wallet server / miner.
This instance had a 1TB Elastic Block Store volume attached to it (1TB is max EBS volume size on AWS). I made this volume available to the network using NFS

I then created a "plot generator" instance with much higher CPU capacity (C3.xlarge 8 core). I mounted the shared volume so it appeared like a local disk and started creating 10GB plots
I then created a few scripts so that upon startup the instance would auto-mount the NFS volume, figure out what the last used nonce range was, and start mining from the next 10GB plot
Finally, I created an image of this instance and spooled up 100 more instances like it (spot rates, nice and cheap).

To begin with it all looked great but I soon hit the bandwidth limit of the instance I was using as the server.  In essence the server didn't have enough network bandwidth to cope with all of the data being copied to it.  This restricted plot creation to a little over 100GB / hour.  Changing the instance type of the server instance to one with a "high" network performance got this up to around 400 GB/hour.  If I had have left it running I would have created all 1 TB of plots in 2.5 hours, at a cost of around $20.  This could have been repeated or even parallelized to create several 1TB volumes full of plots in a relatively short amount of time.

After all the fiddling about getting it working, I spent around $70 testing this stuff out, only to conclude it was too much hassle.  And as OP said earlier, the cost of EBS storage on AWS is too high to make this a viable long term mining option.  That said, had I have done all of this on day one, I would have scaled the process out and had 10TB+ up within the first few hours and dominated the mining.  Good to know I have the process licked for the next PoC coin Smiley

Unfortunately I STILL don't have any BURST as I don't have any spare capacity at home so haven't been able to mine at all Sad  So if anyone would like to donate some coins to offset the cost of testing all of this, my address is BURST-WADY-CBZE-HSJU-2NH5G

Many thanks!

At $70 per day, that's $2100 per month. You can nearly buy a mobo, a used 6/12 core (12/24 threads) Intel cpu, Ram and some HDD's for that price, give or take....LOL
989  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 09:32:20 AM
I created a thread specially for mining Burst/PoC coins. It has a spreadsheet to share data to the community. Here's the link: https://bitcointalk.org/index.php?topic=740158.new#new

Hope the dev can put this on the OP.
990  Alternate cryptocurrencies / Mining (Altcoins) / Proof of HDD Capacity (PoC) Mining Config/Data Sharing/Collaboration on: August 15, 2014, 09:28:59 AM
Hi everyone, hope everyone that is mining Burst is enjoying it and finding blocks.

I just wanted to create this thread to sharing info and ideas to improve mining Burst or any future PoC coin.

Here is an rough draft of a google spreadsheet I created, please add to it: https://docs.google.com/spreadsheets/d/1uaXMLjLt90Ms1oRjcjz-eYPOkARtNS8JdrKFKOJdg4o/edit?usp=sharing

Everyone should have a fair knowledge to mine and to withhold that knowledge would be not good for the crypto-community in general.

Be glad to see people helping each other out here and please refrain from getting off topic, only talk about mining PoC and issues with it.

If I see any info that is helpful enough to be post on the OP, I will append the OP and add it below.

Thank you everybody,
SD13


Appended Info:


Here's the thread for Burstcoin for cross reference: https://bitcointalk.org/index.php?topic=731923.0

Formula for calculating Plot/Nonce Size: x=HDD used data size in GB

                                                f(x)=Plot/Nonce size

                                                f(x)=4096x

Guides for mining Burst taken from OP and thanks to the guys for supplying it:

Windows mining guide: https://bitcointalk.org/index.php?topic=731923.msg8298999#msg8298999 (thanks to KSpinner)

One thing that cause me a little issue was the wording on KSpinner's guide:

run_generate.bat file
Example for this is:
C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate *youraccount#* *plot#tostartwith* *plot#toendwith* 1000 4

It should have been this:
C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate *your_account_#* *plot_to_start_with_#* *plot_size_#* 1000 4

A note, do not include the asterisks and put number instead in the following words: *your_account_#*, *plot_to_start_with_#*, *plot_size_#*

Your plot size ideally should be the multiple of the number that follows it, that number is the stagger size for each generation/write to the hdd.

Example, I underlined the numbers to show each numbers more clearly:

C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner 1234567890987654321 0 5734400 1024 4

Linux mining guide: https://bitcointalk.org/index.php?topic=731923.msg8299637#msg8299637 (thanks to TetraHect0rCannabinol)

Thanks to dcct, here's a tool to calculate overlapping plots from the Burst thread: https://bchain.info/BURST/tools/overlap
And plot merge tool(Linux only): https://bchain.info/merge.c


UPDATE:
Please do not alter others information on the spreadsheet as a joke, that's downright disrespectful. That would not help the community out.
991  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 08:53:28 AM
to the DEV ... i musst ask again...

i have this: (overlapping is only bad for diskspace?)
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4

or should i use this?
run_generate.bat <address> 0 500000 4000 4                (128GB)
run_generate.bat <address> 500001 500000 4000 4        (128GB)
run_generate.bat <address> 1000001 500000 2000 4      (128GB)

and second.
if i have i big gap like this.. do i need ploting the missing file for correct mining or can i move to the next plot?
i mean do i ned a coherent chain ??
1. run_generate.bat <address> 0 500000 4000 4                (128GB)
2. (missing file of 128GB)
3. run_generate.bat <address> 1000001 500000 2000 4      (128GB)
4. (next plot: 1500001 500000 2000 4)
Either is fine. Technically, 500000 plots starting from 0 is 0 - 499999, so the second has a gap of 1 in between the first 2, but that doesn't matter.

Overlapping is bad since it calculates to the same result in multiple places, wasting disk space and doing unnecessary work.
There is no problem with having gaps.
This:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4
is just as good as this:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 5000000000 500000 4000 4
run_generate.bat <address> 9898000000 500000 2000 4

So, staggering is best implemented on the same drive. But on multiple drives, you can start from each one at 0 if you wanted to with one large plot for each. If I'm understanding this correctly. I notice that it seems that most people are more successful making smaller multiple plots on hdd's than one larger one.

So, the formula for calculating nonce size is this: x=Nonce size

                                                                  f(x)=hdd size in GB

                                                                  (256x)/10^6=f(x)

                                                                   x=[f(x)*10^6]/256


its not 10^6 but 1024^2

That's an approximate, but so this would be the end result then: x=[f(x)*1024^2]/256

you should write it f(x) = x*1024^2/256 (for correct mathematical expression), where x is disk size in GB and f(x) is nonce count

anyway, more correct and simple equation form is f(x) = x*4096 , where x in GB of disk size

But yeah I should have reverse that. Not wrong either way depending what is selected as the range or domain, that's the beauty of Algebra. So, to even clean it up more, it's simple this: f(x)=4096x . Thanks
992  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 08:36:52 AM
to the DEV ... i musst ask again...

i have this: (overlapping is only bad for diskspace?)
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4

or should i use this?
run_generate.bat <address> 0 500000 4000 4                (128GB)
run_generate.bat <address> 500001 500000 4000 4        (128GB)
run_generate.bat <address> 1000001 500000 2000 4      (128GB)

and second.
if i have i big gap like this.. do i need ploting the missing file for correct mining or can i move to the next plot?
i mean do i ned a coherent chain ??
1. run_generate.bat <address> 0 500000 4000 4                (128GB)
2. (missing file of 128GB)
3. run_generate.bat <address> 1000001 500000 2000 4      (128GB)
4. (next plot: 1500001 500000 2000 4)
Either is fine. Technically, 500000 plots starting from 0 is 0 - 499999, so the second has a gap of 1 in between the first 2, but that doesn't matter.

Overlapping is bad since it calculates to the same result in multiple places, wasting disk space and doing unnecessary work.
There is no problem with having gaps.
This:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4
is just as good as this:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 5000000000 500000 4000 4
run_generate.bat <address> 9898000000 500000 2000 4

So, staggering is best implemented on the same drive. But on multiple drives, you can start from each one at 0 if you wanted to with one large plot for each. If I'm understanding this correctly. I notice that it seems that most people are more successful making smaller multiple plots on hdd's than one larger one.

So, the formula for calculating nonce size is this: x=Nonce size

                                                                  f(x)=hdd size

                                                                  (256x)/10^6=f(x)

                                                                   x=[f(x)*10^6]/256


its not 10^6 but 1024^2

That's an approximate, but so this would be the end result then: x=[f(x)*1024kb^2]/256kb
993  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 15, 2014, 08:30:47 AM
to the DEV ... i musst ask again...

i have this: (overlapping is only bad for diskspace?)
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4

or should i use this?
run_generate.bat <address> 0 500000 4000 4                (128GB)
run_generate.bat <address> 500001 500000 4000 4        (128GB)
run_generate.bat <address> 1000001 500000 2000 4      (128GB)

and second.
if i have i big gap like this.. do i need ploting the missing file for correct mining or can i move to the next plot?
i mean do i ned a coherent chain ??
1. run_generate.bat <address> 0 500000 4000 4                (128GB)
2. (missing file of 128GB)
3. run_generate.bat <address> 1000001 500000 2000 4      (128GB)
4. (next plot: 1500001 500000 2000 4)
Either is fine. Technically, 500000 plots starting from 0 is 0 - 499999, so the second has a gap of 1 in between the first 2, but that doesn't matter.

Overlapping is bad since it calculates to the same result in multiple places, wasting disk space and doing unnecessary work.
There is no problem with having gaps.
This:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 500000 500000 4000 4
run_generate.bat <address> 1000000 500000 2000 4
is just as good as this:
run_generate.bat <address> 0 500000 4000 4
run_generate.bat <address> 5000000000 500000 4000 4
run_generate.bat <address> 9898000000 500000 2000 4

So, staggering is best implemented on the same drive. But on multiple drives, you can start from each one at 0 if you wanted to with one large plot for each. If I'm understanding this correctly. I notice that it seems that most people are more successful making smaller multiple plots on hdd's than one larger one.

So, the formula for calculating nonce size is this: x=Nonce size

                                                                  f(x)=hdd size in GB

                                                                  (256x)/10^6=f(x)

                                                                   x=[f(x)*10^6]/256
994  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 12:26:19 PM
Raid5 won't help much since you even sacrifice one disk, if you set it up just for mining go jbod or raid0...

And yes, people are expanding and still building their systems, plot generation is awfully slow.

JBOD and RAID0 have no form of parity. JBOD can be recovered compared to RAID0, but RAID5 has parity and more performance than JBOD. One disk sacrifice is better than losing all the data possible, especially on RAID0. Originally I was going to do a RAID0/JBOD, but after thinking about it, I didn't want the chance of failure. Good thing about JBOD, you can mix and match hdd's, and use their full capacity. As with RAID, you ideally want to match identical hdd's.

Your point?

I wouldn't post that if i didnt know what i am talking about but thanks for the lesson...

Why should i care about parity for some mining plots i can even recreat exact copies of IF a drive fails...one more drive is imho worth more than the slight chance that ONE drive will fail within the next days / weeks.

You have your opinion and I have mine, I respect yours...

I guess I'll just wait and see how it goes with this small 500GB hdd before investing into a few 4TB drives.

For normal world use i would always go raid5 / raidZ but not for plot generation, no offense Smiley

I am using FreeNAS ZFS in my home server.

No offense taken, your free to speak and think. It's not like your trying to kill my family, insult my religion and/or anything major like that...lol

Just annoying to recreate plots, if that needs to be done.
995  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 12:23:01 PM
why create a raid anyway ... e.g. for windows you can simply hardlink plot-files from different drives to your mining 'plots' folder ...
Code:
mklink /h c:\pocminer\plots\your_plot_file x:\your_plot_file

Just simplicity. Guess you can do that too.
996  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 12:19:39 PM
Raid5 won't help much since you even sacrifice one disk, if you set it up just for mining go jbod or raid0...

And yes, people are expanding and still building their systems, plot generation is awfully slow.

JBOD and RAID0 have no form of parity. JBOD can be recovered compared to RAID0, but RAID5 has parity and more performance than JBOD. One disk sacrifice is better than losing all the data possible, especially on RAID0. Originally I was going to do a RAID0/JBOD, but after thinking about it, I didn't want the chance of failure. Good thing about JBOD, you can mix and match hdd's, and use their full capacity. As with RAID, you ideally want to match identical hdd's.

Your point?

I wouldn't post that if i didnt know what i am talking about but thanks for the lesson...

Why should i care about parity for some mining plots i can even recreat exact copies of IF a drive fails...one more drive is imho worth more than the slight chance that ONE drive will fail within the next days / weeks.

You have your opinion and I have mine, I respect yours...

I guess I'll just wait and see how it goes with this small 500GB hdd before investing into a few 4TB drives.
997  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 11:58:46 AM
Raid5 won't help much since you even sacrifice one disk, if you set it up just for mining go jbod or raid0...

And yes, people are expanding and still building their systems, plot generation is awfully slow.

JBOD and RAID0 have no form of parity. JBOD can be recovered compared to RAID0, but RAID5 has parity and more performance than JBOD. One disk sacrifice is better than losing all the data possible, especially on RAID0. Originally I was going to do a RAID0/JBOD, but after thinking about it, I didn't want the chance of failure. Good thing about JBOD, you can mix and match hdd's, and use their full capacity. As with RAID, you ideally want to match identical hdd's.
998  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 11:44:02 AM
Getting a pool together would be great

Its been 48 hours and still no block.
Im waiting to see if this actually works before getting ahold of several harddrives.

Same here. It is cheaper to buy a bunch of hdd's compared to gpu cards, but results have to be worth it first. I haven't found a block since I started 60 hours ago on a 500gb drive. But I keep seeing people with smaller drives find blocks and/or find block within 6 hours of starting mining on a hdd. Luck or have people found the optimal setting to mine with?

You did start the wallet and the miner - right?

Got all 3 bats working(run,generate and wallet), I am technically inclined and Cisco CCNA certified. I just barely got the plot to finish a couple minutes ago. I did a 400GB plot on the 500gb drive.

My guess is that you should avg at least one block per day, no sure way to tell without knowing the diff though -.-

Solo mining is highly luck base compare to pool mining. Plus, there is no way to know the diff or whatever is like a diff for this coin. So, there is no way to calculate block per day.

Sure, you take your own hashrate (plotsize)  and avg the blocks per day, break it down -> avg blocks per day.

Doesn't really work though because the net is in its main growing stage and my hashrate is expending too, i can post some numbers after the weekend though, i'll be done with plot generation tomorrow, running 4700GB
Getting a pool together would be great

Its been 48 hours and still no block.
Im waiting to see if this actually works before getting ahold of several harddrives.

Same here. It is cheaper to buy a bunch of hdd's compared to gpu cards, but results have to be worth it first. I haven't found a block since I started 60 hours ago on a 500gb drive. But I keep seeing people with smaller drives find blocks and/or find block within 6 hours of starting mining on a hdd. Luck or have people found the optimal setting to mine with?

You did start the wallet and the miner - right?

Got all 3 bats working(run,generate and wallet), I am technically inclined and Cisco CCNA certified. I just barely got the plot to finish a couple minutes ago. I did a 400GB plot on the 500gb drive.

My guess is that you should avg at least one block per day, no sure way to tell without knowing the diff though -.-

Solo mining is highly luck base compare to pool mining. Plus, there is no way to know the diff or whatever is like a diff for this coin. So, there is no way to calculate block per day.

Sure, you take your own hashrate (plotsize)  and avg the blocks per day, break it down -> avg blocks per day.

Doesn't really work though because the net is in its main growing stage and my hashrate is expending too, i can post some numbers after the weekend though, i'll be done with plot generation tomorrow, running 4700GB

That average will work for a week, then it will change next week because all the big miners will have there storage servers mining. That will surely make mining difficulty for the smaller miner. Gpu mining all over again...LOL

I do plan to do a RAID 5 with 4 drives, once I see I can get a couple of blocks with my current setup.

We need to get together one big chart of settings so we can optimize our setup for the most efficient performance according to how big and many harddrive(s) we have.



That is a very good idea, maybe put up a Google docs spreadsheet that can be linked to the OP.


...

Solo mining is highly luck base compare to pool mining. Plus, there is no way to know the diff or whatever is like a diff for this coin. So, there is no way to calculate block per day.

Code:
/burst?requestType=getBlockchainStatus (GET) Thu Aug 14 2014 13:35:28 GMT+0200

{
"lastBlock": "1014125104951407132",
"lastBlockchainFeederHeight": 1201,
"time": 293728,
"lastBlockchainFeeder": "109.195.211.62",
"numberOfBlocks": 1201,
"isScanning": false,
"cumulativeDifficulty": "67567251495709",
"version": "1.0.0"
}


What about this 'cumulativeDifficulty' ... thought this is the diff?!


No sure if it definitive like gpu/cpu mining. It might be, but it hasn't been exactly elaborated on.
999  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 11:32:11 AM
Getting a pool together would be great

Its been 48 hours and still no block.
Im waiting to see if this actually works before getting ahold of several harddrives.

Same here. It is cheaper to buy a bunch of hdd's compared to gpu cards, but results have to be worth it first. I haven't found a block since I started 60 hours ago on a 500gb drive. But I keep seeing people with smaller drives find blocks and/or find block within 6 hours of starting mining on a hdd. Luck or have people found the optimal setting to mine with?

You did start the wallet and the miner - right?

Got all 3 bats working(run,generate and wallet), I am technically inclined and Cisco CCNA certified. I just barely got the plot to finish a couple minutes ago. I did a 400GB plot on the 500gb drive.

My guess is that you should avg at least one block per day, no sure way to tell without knowing the diff though -.-

Solo mining is highly luck base compare to pool mining. Plus, there is no way to know the diff or whatever is like a diff for this coin. So, there is no way to calculate block per day.
1000  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient Proof of HDD Capacity Mining | No IPO, No Pre on: August 14, 2014, 11:28:52 AM
We need blockchain and exchange. Someone contacted with exchanges?

Everyone of us needs to tweet Bittrex! They will add the coin if they see lot of interest! I've tweeted, do the same!!

why are so many people so urge to sell, saying sell and sell, this coin has no pool yet, and even no logo, how can a coin with no logo lunch the exchange platform? i think dev will do these step by step , at least this coin only came out within five days, he has so many works to do ,, only what you think just mine and sell and sell,,if this coin have some steady pools and lots of miners, and a wonderful design concept, it will lunch the exchange platform sooner or later,i think there is nothing to worry about, all these need  time , need one and one step to develop.

I don't understand either, this isn't power consuming when compared to gpu mining and only uses a small fraction of power. I understand with gpu mining because you have to make a quick ROI for hardware and power cost, but this is low cost for both power cost and hardware.

I would rather have this coin organized in general, have PR started, a website, roadmap, future services/products and then an exchange.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ... 118 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!