[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[katlogic]

oh pluuuze, muh superior pos sales pitch

You do realize there were pure-PoS schemes before NXT, right?

But since we're flaming here and all, here goes equally vague statement:

In Pure-PoS schemes, consensus can be deadlocked to dangerously small number of holders.
Human nature is not always rational, some safeguards are necessary (such as PoW, or
something else of that nature).

I wont explain why is that, just head over to Peercoin thread for detailed criticism of PoS and why it needs a PoW backup.

The future of burst is not in HDD's, it'll be in robots and blurays, and that'll be replaced.

If you want to make the calculation, base it off gpu's, cause burst has no asic's yet, and when it does they won't be BAD. They will be new, better storage devices.

http://www.wired.com/2014/02/facebook-robots/

Also, please note that, if you want to mine effeciently, you could do only like 8 scoops/drive, which means that the drive is off for a majority of the time.

8 scoops would mean that drive only comes on once every 512 blocks.

NOTE: storage is expensive, so perhaps the robots will use waaayyy less power, but the home user with an on computer would always have the upper hand, as their computer is on in any case, and the hdd doesn't use extra power.

Also, https://burstforum.com/index.php?threads/what-about-optical-media.261/

[FakeAccount]

yeah, that's what I found, the windows re-plotter produces corrupted file.  it was incorrect size given stagger size etc...
localhost is fine.  I tested that with other files to make sure.

BURST miner, v1.141020
Programming: dcct (Linux) & Blago (Windows)
CPU support:  AES  SSE4  AVX  AVX2
Node: localhost (ip: 127.0.0.1)
Node: localhost (ip: 127.0.0.1)
Using plots:
Y:\plots\       files: 1         size: 1858 Gb
TOTAL: 1858 Gb

--- 21:14:39 ---    New block 29540, basetarget 2998332    ------------
*** Chance to find a block: 0.02970%
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 790396957
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 392940853
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 392940853       4547d 22h 14m 13s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 165320872
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 143340366
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 143340366       1659d 0h 46m 6s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 27461602
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 27461602        317d 20h 13m 22s
21:14:39 Confirmed DL: 5446372073854    63036713d 19h 37m 34s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  165320872 > 27461602  discarded
21:14:39 Confirmed DL: 6091147647021    70499394d 1h 30m 21s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  790396957 > 27461602  discarded
21:14:39 Confirmed DL: 6134291670940    70998746d 4h 35m 40s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 2275525
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 2275525 26d 8h 5m 25s
21:14:40 Confirmed DL: 5975898902375    69165496d 13h 19m 35s
21:14:40 [xxxxxxxxxxxxxxxxxxx]  found deadline 1561449
21:14:40 [xxxxxxxxxxxxxxxxxxx] sent DL: 1561449 18d 1h 44m 9s
21:14:40 Confirmed DL: 4101564822843    47471815d 1h 54m 3s
21:14:42 [xxxxxxxxxxxxxxxxxxx]  found deadline 915567
21:14:42 [xxxxxxxxxxxxxxxxxxx] sent DL: 915567  10d 14h 19m 27s
21:14:42 Confirmed DL: 5635954431523    65230954d 1h 38m 43s
21:14:48 [xxxxxxxxxxxxxxxxxxx]  found deadline 59908
21:14:48 [xxxxxxxxxxxxxxxxxxx] sent DL: 59908   0d 16h 38m 28s
21:14:48 Confirmed DL: 3470582522731    40168779d 4h 45m 31s
21:14:53 Thread "Y:\plots\" done! [~14 sec] (1 files)
[100%] 1858 GB. deadline 3470582522731s  sdl:7/0(0) cdl:7(0) ss:8(0) rs:8(0)
...

Sent deadlines != confirmed deadlines. Daemon is not synced or plot-file is corrupted.

[vipervince2002]

yeah, that's what I found, the windows re-plotter produces corrupted file.  it was incorrect size given stagger size etc...
localhost is fine.  I tested that with other files to make sure.

BURST miner, v1.141020
Programming: dcct (Linux) & Blago (Windows)
CPU support:  AES  SSE4  AVX  AVX2
Node: localhost (ip: 127.0.0.1)
Node: localhost (ip: 127.0.0.1)
Using plots:
Y:\plots\       files: 1         size: 1858 Gb
TOTAL: 1858 Gb

--- 21:14:39 ---    New block 29540, basetarget 2998332    ------------
*** Chance to find a block: 0.02970%
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 790396957
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 392940853
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 392940853       4547d 22h 14m 13s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 165320872
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 143340366
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 143340366       1659d 0h 46m 6s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 27461602
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 27461602        317d 20h 13m 22s
21:14:39 Confirmed DL: 5446372073854    63036713d 19h 37m 34s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  165320872 > 27461602  discarded
21:14:39 Confirmed DL: 6091147647021    70499394d 1h 30m 21s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  790396957 > 27461602  discarded
21:14:39 Confirmed DL: 6134291670940    70998746d 4h 35m 40s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 2275525
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 2275525 26d 8h 5m 25s
21:14:40 Confirmed DL: 5975898902375    69165496d 13h 19m 35s
21:14:40 [xxxxxxxxxxxxxxxxxxx]  found deadline 1561449
21:14:40 [xxxxxxxxxxxxxxxxxxx] sent DL: 1561449 18d 1h 44m 9s
21:14:40 Confirmed DL: 4101564822843    47471815d 1h 54m 3s
21:14:42 [xxxxxxxxxxxxxxxxxxx]  found deadline 915567
21:14:42 [xxxxxxxxxxxxxxxxxxx] sent DL: 915567  10d 14h 19m 27s
21:14:42 Confirmed DL: 5635954431523    65230954d 1h 38m 43s
21:14:48 [xxxxxxxxxxxxxxxxxxx]  found deadline 59908
21:14:48 [xxxxxxxxxxxxxxxxxxx] sent DL: 59908   0d 16h 38m 28s
21:14:48 Confirmed DL: 3470582522731    40168779d 4h 45m 31s
21:14:53 Thread "Y:\plots\" done! [~14 sec] (1 files)
[100%] 1858 GB. deadline 3470582522731s  sdl:7/0(0) cdl:7(0) ss:8(0) rs:8(0)
...

Sent deadlines != confirmed deadlines. Daemon is not synced or plot-file is corrupted.

I am sorry about the delay,  but I want to ask a couple questions.

First, did the original plot file get automatically deleted when it was done optimizing?
If not,  then it did not complete properly.

Second, did you use any memory optimizers with the delay function?
If you did not use the memory optimizer, did you just the delay function?
Memory optimizers can delete important cache or the delay function may have allowed Windows to delete something important.

Third, how many scoops did you see processed at once?
It has to be 2, 4, 8, 16, 32, 64, ..., 2048, or 4096.

Lastly, is every plot file you optimize coming out corrupted? I have had success with the windows optimizer so I want to figure out what factors I am not accounting for.  I tried to avoid making any changes to dcct's optimization algorithm.

Let me know if any of my suggestions correct your issue. I am also curious if version 1.1 from my previous post works better.

[mczarnek]

oh pluuuze, muh superior pos sales pitch

You do realize there were pure-PoS schemes before NXT, right?

But since we're flaming here and all, here goes equally vague statement:

In Pure-PoS schemes, consensus can be deadlocked to dangerously small number of holders.
Human nature is not always rational, some safeguards are necessary (such as PoW, or
something else of that nature).

I wont explain why is that, just head over to Peercoin thread for detailed criticism of PoS and why it needs a PoW backup.

The future of burst is not in HDD's, it'll be in robots and blurays, and that'll be replaced.

If you want to make the calculation, base it off gpu's, cause burst has no asic's yet, and when it does they won't be BAD. They will be new, better storage devices.

http://www.wired.com/2014/02/facebook-robots/

Also, please note that, if you want to mine effeciently, you could do only like 8 scoops/drive, which means that the drive is off for a majority of the time.

8 scoops would mean that drive only comes on once every 512 blocks.

NOTE: storage is expensive, so perhaps the robots will use waaayyy less power, but the home user with an on computer would always have the upper hand, as their computer is on in any case, and the hdd doesn't use extra power.

Also, https://burstforum.com/index.php?threads/what-about-optical-media.261/

Yes, but Nxt has plans for a system that would enable protection against even 90% of the forging stake attacking the network.  Actually it's a fairly simple and ingenious tweak to the algorithm.. if you don't receive a block within 15 seconds (maybe to be bumped to a minute), then you don't count it's "Base Target" toward the total cumulative score of the chain when choosing the longest chain to follow.

It is true that blockchain trimming would be much trickier.. and probably involves using something along the lines of service providers, where others host the chain for you and you check multiple chains, or every few months or every year or however often you create a 'new genesis block' that includes all the current balances.  But you needing to use data internal to the blockchain means 'lite' clients are probably out of the question, unless you trust others to provide the blockchain up to this point.  Which may be doable, so, they are using economic clustering in order to provide extra protection against attack on the network.  So you can have many big businesses all choose the 'correct' chain they are running on and provide.


But back on topic:

I wasn't trying to insult Burst.. I was thinking about sticking a few BTC into it and I'm just researching my potential investment.

A couple problems with my calculations:
Turns out my calculation was one using an 'energy efficient' hard drive.. which is less reliable.  So you'd pretty much want to use one that works at 10W instead under full load.

Also, I started thinking that maybe you could frequently idle your hard drive but it is believed that's much worse on it's life than continually running it.. so you would want to keep it under full load.. at which point you actually use more energy than the Bitcoin network.  Which is a shame.. I really thought this was a cool idea and might address that problem and that it was basically the whole point of choosing proof of storage over proof of work.  I will admit that reusablity and the fact that this can be made into something that allows everyday people to use that piece of hard drive space that they don't use and get paid some tiny amount for it, is appealing.

It's possible that new and upcoming hard drives will be more efficient and fix this issue but the biggest problem is that their price is going down so much faster than their energy consumption, so this problem will likely become even worse.  And not only that but I suspect that Bitcoin miners will also continue to get more efficient with time.

What are other advantages to using Proof of Capacity over Proof of Work besides energy? 

Ones I see are:
It's pretty ASIC resistant, because if you can make better harddrives.. then you can use them in PCs everywhere.
Related to which, you don't need fancy hardware and if you get a hard drive specifically for this issue.
Hard drives are reusable for other purposes, if they don't die first.

I really do like this coin, just trying to look at it from all angles.


EDIT: WAIT.. I might see what you are saying.. I misunderstood the blu-ray thing since that specific article doesn't mention energy efficiency, but after looking around other places.. I see that those are significantly more energy efficient.  Turning the hardrive on and off is indeed not good for it but only every 512 or so blocks wouldn't be bad.. How long are blocks?

[FakeAccount]

yeah, that's what I found, the windows re-plotter produces corrupted file.  it was incorrect size given stagger size etc...
localhost is fine.  I tested that with other files to make sure.

BURST miner, v1.141020
Programming: dcct (Linux) & Blago (Windows)
CPU support:  AES  SSE4  AVX  AVX2
Node: localhost (ip: 127.0.0.1)
Node: localhost (ip: 127.0.0.1)
Using plots:
Y:\plots\       files: 1         size: 1858 Gb
TOTAL: 1858 Gb

--- 21:14:39 ---    New block 29540, basetarget 2998332    ------------
*** Chance to find a block: 0.02970%
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 790396957
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 392940853
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 392940853       4547d 22h 14m 13s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 165320872
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 143340366
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 143340366       1659d 0h 46m 6s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 27461602
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 27461602        317d 20h 13m 22s
21:14:39 Confirmed DL: 5446372073854    63036713d 19h 37m 34s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  165320872 > 27461602  discarded
21:14:39 Confirmed DL: 6091147647021    70499394d 1h 30m 21s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  790396957 > 27461602  discarded
21:14:39 Confirmed DL: 6134291670940    70998746d 4h 35m 40s
21:14:39 [xxxxxxxxxxxxxxxxxxx]  found deadline 2275525
21:14:39 [xxxxxxxxxxxxxxxxxxx] sent DL: 2275525 26d 8h 5m 25s
21:14:40 Confirmed DL: 5975898902375    69165496d 13h 19m 35s
21:14:40 [xxxxxxxxxxxxxxxxxxx]  found deadline 1561449
21:14:40 [xxxxxxxxxxxxxxxxxxx] sent DL: 1561449 18d 1h 44m 9s
21:14:40 Confirmed DL: 4101564822843    47471815d 1h 54m 3s
21:14:42 [xxxxxxxxxxxxxxxxxxx]  found deadline 915567
21:14:42 [xxxxxxxxxxxxxxxxxxx] sent DL: 915567  10d 14h 19m 27s
21:14:42 Confirmed DL: 5635954431523    65230954d 1h 38m 43s
21:14:48 [xxxxxxxxxxxxxxxxxxx]  found deadline 59908
21:14:48 [xxxxxxxxxxxxxxxxxxx] sent DL: 59908   0d 16h 38m 28s
21:14:48 Confirmed DL: 3470582522731    40168779d 4h 45m 31s
21:14:53 Thread "Y:\plots\" done! [~14 sec] (1 files)
[100%] 1858 GB. deadline 3470582522731s  sdl:7/0(0) cdl:7(0) ss:8(0) rs:8(0)
...

Sent deadlines != confirmed deadlines. Daemon is not synced or plot-file is corrupted.

I am sorry about the delay,  but I want to ask a couple questions.

First, did the original plot file get automatically deleted when it was done optimizing?
If not,  then it did not complete properly.

Second, did you use any memory optimizers with the delay function?
If you did not use the memory optimizer, did you just the delay function?
Memory optimizers can delete important cache or the delay function may have allowed Windows to delete something important.

Third, how many scoops did you see processed at once?
It has to be 2, 4, 8, 16, 32, 64, ..., 2048, or 4096.

Lastly, is every plot file you optimize coming out corrupted? I have had success with the windows optimizer so I want to figure out what factors I am not accounting for.  I tried to avoid making any changes to dcct's optimization algorithm.

Let me know if any of my suggestions correct your issue. I am also curious if version 1.1 from my previous post works better.

original file got deleted. (which I didn't like since I had to re-create oroginal file again... maybe it would be better to create a parameter to control this?)

i did not use any delaying.  just specified 1 gig of memory

2 scoops

don't know if every plot.  can try on another plot, but first need to make a copy of it since I don't want to lose the original plot, so this will take some time.

[callmejack]

oh pluuuze, muh superior pos sales pitch

You do realize there were pure-PoS schemes before NXT, right?

But since we're flaming here and all, here goes equally vague statement:

In Pure-PoS schemes, consensus can be deadlocked to dangerously small number of holders.
Human nature is not always rational, some safeguards are necessary (such as PoW, or
something else of that nature).

I wont explain why is that, just head over to Peercoin thread for detailed criticism of PoS and why it needs a PoW backup.

The future of burst is not in HDD's, it'll be in robots and blurays, and that'll be replaced.

If you want to make the calculation, base it off gpu's, cause burst has no asic's yet, and when it does they won't be BAD. They will be new, better storage devices.

http://www.wired.com/2014/02/facebook-robots/

Also, please note that, if you want to mine effeciently, you could do only like 8 scoops/drive, which means that the drive is off for a majority of the time.

8 scoops would mean that drive only comes on once every 512 blocks.

NOTE: storage is expensive, so perhaps the robots will use waaayyy less power, but the home user with an on computer would always have the upper hand, as their computer is on in any case, and the hdd doesn't use extra power.

Also, https://burstforum.com/index.php?threads/what-about-optical-media.261/

Yes, but Nxt has plans for a system that would enable protection against even 90% of the forging stake attacking the network.  Actually it's a fairly simple and ingenious tweak to the algorithm.. if you don't receive a block within 15 seconds (maybe to be bumped to a minute), then you don't count it's "Base Target" toward the total cumulative score of the chain when choosing the longest chain to follow.

It is true that blockchain trimming would be much trickier.. and probably involves using something along the lines of service providers, where others host the chain for you and you check multiple chains, or every few months or every year or however often you create a 'new genesis block' that includes all the current balances.  But you needing to use data internal to the blockchain means 'lite' clients are probably out of the question, unless you trust others to provide the blockchain up to this point.  Which may be doable, so, they are using economic clustering in order to provide extra protection against attack on the network.  So you can have many big businesses all choose the 'correct' chain they are running on and provide.


But back on topic:

I wasn't trying to insult Burst.. I was thinking about sticking a few BTC into it and I'm just researching my potential investment.

A couple problems with my calculations:
Turns out my calculation was one using an 'energy efficient' hard drive.. which is less reliable.  So you'd pretty much want to use one that works at 10W instead under full load.

Also, I started thinking that maybe you could frequently idle your hard drive but it is believed that's much worse on it's life than continually running it.. so you would want to keep it under full load.. at which point you actually use more energy than the Bitcoin network.  Which is a shame.. I really thought this was a cool idea and might address that problem and that it was basically the whole point of choosing proof of storage over proof of work.  I will admit that reusablity and the fact that this can be made into something that allows everyday people to use that piece of hard drive space that they don't use and get paid some tiny amount for it, is appealing.

It's possible that new and upcoming hard drives will be more efficient and fix this issue but the biggest problem is that their price is going down so much faster than their energy consumption, so this problem will likely become even worse.  And not only that but I suspect that Bitcoin miners will also continue to get more efficient with time.

What are other advantages to using Proof of Capacity over Proof of Work besides energy? 

Ones I see are:
It's pretty ASIC resistant, because if you can make better harddrives.. then you can use them in PCs everywhere.
Related to which, you don't need fancy hardware and if you get a hard drive specifically for this issue.
Hard drives are reusable for other purposes, if they don't die first.

I really do like this coin, just trying to look at it from all angles.


EDIT: WAIT.. I might see what you are saying.. I misunderstood the blu-ray thing since that specific article doesn't mention energy efficiency, but after looking around other places.. I see that those are significantly more energy efficient.  Also, could someone explain how the algorithm works?  Is it called Plotting? Scooping?  How can you only read the data every 512 blocks?  I'm assuming 1 minute blocks since based on Nxt?

the bluray storage for now is only useful for really offline stored data. this may change as soon as blueray disks become much cheaper than hdds. the main effort for facebook to be able to invest into this technology is that they have to keep really much data for legal reasons which is randomly accessed once if ever. i looked into alternative storage methods for burst almost three month back. for each block only 1/4096 is read from your plots but which part this is depends on the previous block. if you think of putting 100tb into some sort of cold storage you have to have almost instant access to "random" 25 gb within the blocktime.
for the case of blueray this means you require to read half of a disk within 4 minutes or even faster. the speed is limited to a maximum of 36 mb/s (8x) on the outer sectors and physically limited due to the facts that the medium rotates.
current holographic storage approaches look promising but there is no company releasing any products to public. eg. inphase announced to release a 300gb storage media for 180$ in 2007 and to release them in 2009. this means if the technology works it would be the perfect base to store your plots.
however, i just want to point out that hdds may not stay the only way to store your plotfiles in near future.

[FakeAccount]

I'm still struggling with win7 64bit and it's memory insanity.  Does win 8 have same issues as win7?

keep hitting "File xxxxxxxxxxx locked?" messages and as a result not 100% of files are read.
When your miner gets this condition/error, could you have that specific thread pause for x number of seconds and then retry the same file where it left off?
...
What do you think about adding this option?  or maybe there's another way to achieve similar control?

Soon will add this option and re-reading problem files

Thanks!!  a previous version of your miner used to say which file a particular deadline came from. any way you can put that back into the miner?  doesn't have to be on the display, write to the logfile is enough.  sometimes it would be useful when submitted DL doesn't get confirmed, that way I could track down which plot file it is and check if it got corrupted somehow.  it would be helpful to get this info back at least into the logfile

[mczarnek]

the bluray storage for now is only useful for really offline stored data. this may change as soon as blueray disks become much cheaper than hdds. the main effort for facebook to be able to invest into this technology is that they have to keep really much data for legal reasons which is randomly accessed once if ever. i looked into alternative storage methods for burst almost three month back. for each block only 1/4096 is read from your plots but which part this is depends on the previous block. if you think of putting 100tb into some sort of cold storage you have to have almost instant access to "random" 25 gb within the blocktime.
for the case of blueray this means you require to read half of a disk within 4 minutes or even faster. the speed is limited to a maximum of 36 mb/s (8x) on the outer sectors and physically limited due to the facts that the medium rotates.
current holographic storage approaches look promising but there is no company releasing any products to public. eg. inphase announced to release a 300gb storage media for 180$ in 2007 and to release them in 2009. this means if the technology works it would be the perfect base to store your plots.
however, i just want to point out that hdds may not stay the only way to store your plotfiles in near future.

Ok, so hdd are still currently the best techonology.. if you can turn it off or on for extended periods of time, maybe energy efficiency isn't a big deal.

It's an interesting algorithm, couple thing I'm trying to figure out if someone could help me out:

How reliably can you be sure when it'll be your turn to mine?  I guess multiple people could potentially mine this block but it's just the person with the highest number wins or something like that?

Also, I mostly understand how you create the plots from reading the introduction.. how do you then verify that you pulled out the correct one and that you have rights to author the block to the rest of the network in a way that they can verify it.. seems to me like the rest of the network would almost have to do a lot of heavy duty hashing to copy the way you generated that number in the first place and arrive at the same number in order to verify it.  Must be some way around that?

[Irontiga]

the bluray storage for now is only useful for really offline stored data. this may change as soon as blueray disks become much cheaper than hdds. the main effort for facebook to be able to invest into this technology is that they have to keep really much data for legal reasons which is randomly accessed once if ever. i looked into alternative storage methods for burst almost three month back. for each block only 1/4096 is read from your plots but which part this is depends on the previous block. if you think of putting 100tb into some sort of cold storage you have to have almost instant access to "random" 25 gb within the blocktime.
for the case of blueray this means you require to read half of a disk within 4 minutes or even faster. the speed is limited to a maximum of 36 mb/s (8x) on the outer sectors and physically limited due to the facts that the medium rotates.
current holographic storage approaches look promising but there is no company releasing any products to public. eg. inphase announced to release a 300gb storage media for 180$ in 2007 and to release them in 2009. this means if the technology works it would be the perfect base to store your plots.
however, i just want to point out that hdds may not stay the only way to store your plotfiles in near future.

Ok, so hdd are still currently the best techonology.. if you can turn it off or on for extended periods of time, maybe energy efficiency isn't a big deal.

It's an interesting algorithm, couple thing I'm trying to figure out if someone could help me out:

How reliably can you be sure when it'll be your turn to mine?  I guess multiple people could potentially mine this block but it's just the person with the highest number wins or something like that?

Also, I mostly understand how you create the plots from reading the introduction.. how do you then verify that you pulled out the correct one and that you have rights to author the block to the rest of the network in a way that they can verify it.. seems to me like the rest of the network would almost have to do a lot of heavy duty hashing to copy the way you generated that number in the first place and arrive at the same number in order to verify it.  Must be some way around that?

You can mine with ur gpu etc. But due to the whole scoop thing, if you mine with cpu/gpu it is highly inefficient. 1 in 4096 blocks a scoop becomes valid, were it 1 in 16000 then cppu's would be advantaged, were it 1 in 512 ssd's would be advantaged. You get the picture? BTW, i'm on irc, so come #burst-coin

Check out the op, diagram there, and also, blocks are 4 minutes

[Irontiga]

We need investors with a lot of burst, pm me if ur minorly interested

[jsmit332]

This is meant as a quick start guide for those having issues with setting their system up on windows. This might be useful for those not familiar with the NXT platform...

First download this:
Wallet: https://mega.co.nz/#!ml4RTKBR!8g0-7RNjkIowgIJuhu-GHLXJRkKRxBlGh_tkbI4Sar4

Next download this:
POCMiner: https://mega.co.nz/#!b0pzHajA!ERk068l5NS6kR7zdLdTgltqyPw3Z60lwAWvgXtNQNTk

And lastly, ensure that you have the latest Java downloaded onto your PC. It seems as though incorrect java versions and correct java installation were the main causes of 50% of the problems listed in the beginning pages.

Step 1: Extract everything to the root of the drive you want to use (ie. the main driver directory). You should wind up with everything from the pocminer_v1 folder showing in the root directory, and with the Burst_1.0.0 folder in the root directory (containing the wallet program).
***you cannot extract this file to the root along with the miner, as they both contain files with the same names, and they will overwrite one or the other. Just leave the wallet in its own folder***

Step 2: Type a PASSWORD of your choosing into the passphrase text doc and save it.

Step 3: If using windows, replace the first word "java" in each of the .bat files with "C:\Windows\SysWOW64\java" and "save as" each of them as .bat files again.

Example for the run_generate .bat file:
Original; java -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate %*

modified: C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate %*

Step 3a: Many of the values in the original .bat files were causing issues for my computer, so I changed the -Xmx4000m (or whatever your # was) to a lower value like 1000 or 500 (ie. -Xmx1000m) and it began working. This will be entirely system dependent, and is like tweaking a normal miner's settings to find what works best.

Step 4: Double click the run_dump_address .bat file

Step 5: check the address .txt file and retrieve your your account #

Example for address is:
Found address: *whateverpassyouentered* -> *youraccount#*

Step 6: Copy your account number and paste it into the run_generate .bat file along with your plot description and how many threads you wish to use. plottostartwith=0 or 1 / plottoendwith=800000 (for every 200 Gig section)

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

Step 7: Double click the run_generate .bat file and a command window should open, and you should see the computer begin to start creating plots, beginning with whatever you specified in your file.
*THIS TAKES A LONG TIME* (you can still start mining while creating plots, but don't expect your chances to be high within the first 8-10 hrs. It also took me personally about 8 hrs to plot my first 200 Gig section, so go watch a movie or get a bite to eat when this guide is done)

Step 8: Double click the run .bat and it will open briefly and then close.

Step 9: Open the Burst_1.0.0 folder and Double click the run .bat file there and let it install

Step 10: double click the Burst_Wallet internet shortcut file

Step 11: enter your password (which is the one you entered into the passphrase text file earlier). This should open your account "front end" gui.

Step 12: Go back to the root directory and double click the run_mine .bat file.

At this point you should have a total of 3 command line windows open...your computer should be generating plots in one command window, have initialized the Burst server and come to the nxt.apiServerEnforcePOST="true" line in another, and yet a thrid command window should be displaying your mining. The mining will repeatedly generate lines such as:

{"height":"2","generationSignature":"c26ef60f51aa5fc6225a481f08e51903085067a8a7d
558f94712d702f2a67bb4"}
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
Error reading file: 10818239041755946932_1_800000_500
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
New best: 10818239041755946932:160093
Submitting share
{"result":"deadline: 508"}

This is good, and it means YOU ARE NOW MINING. The "deadline" is a measurement of seconds until you may generate a block (provided no one else has already generated one). Yes, it is a bit of a race, but as your plot # increases, so do your chances of hitting/solving a block. I believe you can compare the size of your plot to what would be your hashrate if mining a normal scrypt coin.

Any other issues with a single step can be analyzed by typing "pause" on a seperate line in any of the .bat files, which will give you time to read and post whatever error you are experiencing.

If there is anything I left out feel free to let me know or just add to this. Donations to BURST-H2ZW-3H4D-RJBS-FCVGV
or 15977480701804512252

I am trying to start mining using my C drive. i have followed the steps in the windows guide that is provides in the OP and i am stuck on step 4. When i run "run_dump_address" i get this:



If this is relevant, i have not funded my wallet yet.

Can anyone help me?

[Irontiga]

This is meant as a quick start guide for those having issues with setting their system up on windows. This might be useful for those not familiar with the NXT platform...

First download this:
Wallet: https://mega.co.nz/#!ml4RTKBR!8g0-7RNjkIowgIJuhu-GHLXJRkKRxBlGh_tkbI4Sar4

Next download this:
POCMiner: https://mega.co.nz/#!b0pzHajA!ERk068l5NS6kR7zdLdTgltqyPw3Z60lwAWvgXtNQNTk

And lastly, ensure that you have the latest Java downloaded onto your PC. It seems as though incorrect java versions and correct java installation were the main causes of 50% of the problems listed in the beginning pages.

Step 1: Extract everything to the root of the drive you want to use (ie. the main driver directory). You should wind up with everything from the pocminer_v1 folder showing in the root directory, and with the Burst_1.0.0 folder in the root directory (containing the wallet program).
***you cannot extract this file to the root along with the miner, as they both contain files with the same names, and they will overwrite one or the other. Just leave the wallet in its own folder***

Step 2: Type a PASSWORD of your choosing into the passphrase text doc and save it.

Step 3: If using windows, replace the first word "java" in each of the .bat files with "C:\Windows\SysWOW64\java" and "save as" each of them as .bat files again.

Example for the run_generate .bat file:
Original; java -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate %*

modified: C:\Windows\SysWOW64\java -Xmx1000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate %*

Step 3a: Many of the values in the original .bat files were causing issues for my computer, so I changed the -Xmx4000m (or whatever your # was) to a lower value like 1000 or 500 (ie. -Xmx1000m) and it began working. This will be entirely system dependent, and is like tweaking a normal miner's settings to find what works best.

Step 4: Double click the run_dump_address .bat file

Step 5: check the address .txt file and retrieve your your account #

Example for address is:
Found address: *whateverpassyouentered* -> *youraccount#*

Step 6: Copy your account number and paste it into the run_generate .bat file along with your plot description and how many threads you wish to use. plottostartwith=0 or 1 / plottoendwith=800000 (for every 200 Gig section)

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

Step 7: Double click the run_generate .bat file and a command window should open, and you should see the computer begin to start creating plots, beginning with whatever you specified in your file.
*THIS TAKES A LONG TIME* (you can still start mining while creating plots, but don't expect your chances to be high within the first 8-10 hrs. It also took me personally about 8 hrs to plot my first 200 Gig section, so go watch a movie or get a bite to eat when this guide is done)

Step 8: Double click the run .bat and it will open briefly and then close.

Step 9: Open the Burst_1.0.0 folder and Double click the run .bat file there and let it install

Step 10: double click the Burst_Wallet internet shortcut file

Step 11: enter your password (which is the one you entered into the passphrase text file earlier). This should open your account "front end" gui.

Step 12: Go back to the root directory and double click the run_mine .bat file.

At this point you should have a total of 3 command line windows open...your computer should be generating plots in one command window, have initialized the Burst server and come to the nxt.apiServerEnforcePOST="true" line in another, and yet a thrid command window should be displaying your mining. The mining will repeatedly generate lines such as:

{"height":"2","generationSignature":"c26ef60f51aa5fc6225a481f08e51903085067a8a7d
558f94712d702f2a67bb4"}
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
Error reading file: 10818239041755946932_1_800000_500
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
{"height":"3","generationSignature":"a62b500a5dfc7f5e614fcf4917d83ffccd01e9c9643
d7d0e982c75043d27baff"}
New best: 10818239041755946932:160093
Submitting share
{"result":"deadline: 508"}

This is good, and it means YOU ARE NOW MINING. The "deadline" is a measurement of seconds until you may generate a block (provided no one else has already generated one). Yes, it is a bit of a race, but as your plot # increases, so do your chances of hitting/solving a block. I believe you can compare the size of your plot to what would be your hashrate if mining a normal scrypt coin.

Any other issues with a single step can be analyzed by typing "pause" on a seperate line in any of the .bat files, which will give you time to read and post whatever error you are experiencing.

If there is anything I left out feel free to let me know or just add to this. Donations to BURST-H2ZW-3H4D-RJBS-FCVGV
or 15977480701804512252

I am trying to start mining using my C drive. i have followed the steps in the windows guide that is provides in the OP and i am stuck on step 4. When i run "run_dump_address" i get this:



If this is relevant, i have not funded my wallet yet.

Can anyone help me?

That's a very old guide

https://docs.google.com/document/d/1Bc1LIG0vOYYW6FxgBHhQGjKqm0aWoSClkqaNJx17wWk/edit

A new one, and it's comprehensive

[mczarnek]

It's an interesting algorithm, couple thing I'm trying to figure out if someone could help me out:

How reliably can you be sure when it'll be your turn to mine?  I guess multiple people could potentially mine this block but it's just the person with the highest number wins or something like that?

Also, I mostly understand how you create the plots from reading the introduction.. how do you then verify that you pulled out the correct one and that you have rights to author the block to the rest of the network in a way that they can verify it.. seems to me like the rest of the network would almost have to do a lot of heavy duty hashing to copy the way you generated that number in the first place and arrive at the same number in order to verify it.  Must be some way around that?

You can mine with ur gpu etc. But due to the whole scoop thing, if you mine with cpu/gpu it is highly inefficient. 1 in 4096 blocks a scoop becomes valid, were it 1 in 16000 then cppu's would be advantaged, were it 1 in 512 ssd's would be advantaged. You get the picture? BTW, i'm on irc, so come #burst-coin

Check out the op, diagram there, and also, blocks are 4 minutes

I don't understand why does 4096 optimize it for hdd?  Simply because there is so much data to hold on to per plot? Why not SDDs?

Given this:
Plots are generated by taking a public address and a nonce, then hashing it, pre-appending the resulting hash, repeating the hash-pre-append cycle many times, and then hashing the whole thing and xor'ing the last hash with the whole thing.

First of all, how does someone win the right to author their first block?

After authoring their first block, they then take the last block they authored, and use the next scoop from their plot, in order to prove they have the right to author their next block? Then when they get to the end repeat from the beginning?  Is there a concept of difficulty?

I understand how the plots are overlapped but I don't understand how he can claim sequential reads.  All plots don't stay in sync with each other right?  You could be further along in one plot than the other right?

Also, have any coders looked through this coded and approved or has only one guy written it?  People analyzed the algorithm looking for flaws?

[FakeAccount]

I'm still struggling with win7 64bit and it's memory insanity.  Does win 8 have same issues as win7?

keep hitting "File xxxxxxxxxxx locked?" messages and as a result not 100% of files are read.
When your miner gets this condition/error, could you have that specific thread pause for x number of seconds and then retry the same file where it left off?
...
What do you think about adding this option?  or maybe there's another way to achieve similar control?

Soon will add this option and re-reading problem files

there's another "simple?" solution I'd like to propose.  Instead of having just:

"Paths":["A:\\plots","B:\\plots","C:\\plots","D:\\plots","E:\\plots","F:\\plots","G:\\plots","H:\\plots","I:\\plots","J:\\plots","K:\\plots","L:\\plots","M:\\plots","N:\\plots"],

can you allow for multiple "PathsX" and just execute them in order?  so instead of above, I could have something like this instead:

"Paths0":["A:\\plots","B:\\plots","C:\\plots","D:\\plots","E:\\plots","F:\\plots"],
"Paths1":["G:\\plots","H:\\plots","I:\\plots","J:\\plots","K:\\plots","L:\\plots","M:\\plots","N:\\plots"],
......
.....
....
...
..
.
"PathsN":

in my case executing them one after another (manually) takes 78 + 52 seconds whereas having 1 string will kill memory and file locked errors occur and total time exceeds the 78+52=130 seconds...

it wouldn't be too difficult to come up with best choices for each "PathsN" parameter based on size, speed of disk, stagger etc... etc... to come up with the shortest read list that doesnt hit 100% of memory

Thanks!

[timk225]

Just came back from vacation, was gone a full week.  You idiots are still wasting your time on this crap coin?

[majere]

I don't understand why does 4096 optimize it for hdd?

For each nonce/accountId combination a 256 kb chunk of data is pre-generated during the plotting process.
You can specify any ranges of nonces, just make sure they don't overlap. Otherwise same work will be done twice.
Plot files serve as a giant lookup table for further computation. Plot files can be stored on ANY device, hdds, sdds etc. Doesn't matter which device, only the available space matters.

For each block only 64 bytes (scoop) from each 256 kb chunk are really used. These 64 bytes are selected depending on block id (which is not known beforehand).

It's not possible to generate these 64 bytes on the fly. Only the entire 256 kb block can be generated, but only 64 bytes will be used. This makes the algo terribly inefficient for CPU/GPU mining.

As a result of final computation (during mining) a deadline is produced. A person with the shortest deadline will announce the next block once this deadline expires.
I hope this helped to clear things up a bit.

Also, have any coders looked through this coded and approved or has only one guy written it?  People analyzed the algorithm looking for flaws?

I did, haven't found any flaws. The algorithm looks very solid, couldn't find a way to abuse it.
I'm not a cryptography expert though.

[Irontiga]

I don't understand why does 4096 optimize it for hdd?

For each nonce/accountId combination a 256 kb chunk of data is pre-generated during the plotting process.
You can specify any ranges of nonces, just make sure they don't overlap. Otherwise same work will be done twice.
Plot files serve as a giant lookup table for further computation. Plot files can be stored on ANY device, hdds, sdds etc. Doesn't matter which device, only the available space matters.

For each block only 64 bytes (scoop) from each 256 kb chunk are really used. These 64 bytes are selected depending on block id (which is not known beforehand).

It's not possible to generate these 64 bytes on the fly. Only the entire 256 kb block can be generated, but only 64 bytes will be used. This makes the algo terribly inefficient for CPU/GPU mining.

As a result of final computation (during mining) a deadline is produced. A person with the shortest deadline will announce the next block once this deadline expires.
I hope this helped to clear things up a bit.

Also, have any coders looked through this coded and approved or has only one guy written it?  People analyzed the algorithm looking for flaws?

I did, haven't found any flaws. The algorithm looks very solid, couldn't find a way to abuse it.
I'm not a cryptography expert though.

Actually, there is no plotter to plot only 1 scoop, but it is possible. Also, there is no miner. Again, possible.


The thing is with burst, plots are Re-Usable. This pretty much means that, during plotting, you are mining and STORING your hashrate on your HDD. Also, you are not limited to the time in the block. This means that you CAN CPU mine, but not efficiently. So, i have 1 tb, and 1/4096 scoops are valid every block. This means that, for every 1 tb on your hdd, you need to read 256 mb, which also means you are mining with that much stored hashrate. If the nonces became valid once every 512 blocks, then 1tb hdd would require reading 2gb of data, which benefits ssd’s. If it were once every 32768 blocks, a CPU or GPU would be advantaged, because only 32mb would be valid. This would mean in order for a CPU or GPU to keep up, it would only need to generate 32mb worth of data to compete with 1tb. A CPU could do at least close to this. I beleive 4096 hits the sweet spot....cause USB 2.0 is too slow for more than 1tb drives.

EDIT: oops, said noces instead of scoops :/

BTW: I believe a top end i7 can do 7000 nonces/min, which, correct me if i'm worng, = 1.7gb/minute....but that don't sound right.....maybe it's 170mb...

[burstcoin]

Someone want to check my calculations?

I'm calculating that assuming Bitcoin gets 280,000,000 GH/s, then assuming it uses the most energy and cost efficient miner I could find, then it costs $2 per GH and uses 0.5W/GH.

This means that the cost to buy the equipment to power the network is $560,000,000.
Also, the Bitcoin network uses 0.5 W per GH.  In other words 280,000,000 * 0.5 = 140,000,000 W


Now I went with the most energy efficient drive after quickly looking around, I found this: http://www.tomshardware.com/reviews/4tb-3tb-hdd,3183-15.html

The HITACHI Deskstar 5K4000:  http://www.amazon.com/HITACHI-0F14697-Deskstar-5K4000-INTERNAL/dp/B00B6TMG7O

This costs you $130 for 4TB.  So $560,000,000 will buy you ~4,300,000 4TB drives.

4,300,000 drives at 6W per drive gets you 25,800,000 W

Or in other words, ~4 times more energy efficient than Bitcoin..  which is nice but considering how much cheaper it is to forge for Nxt than mine for Bitcoin.. maybe not as much potential as I initially was thinking.  Especially if new Bitcoin mining equipment truly runs at 0.19 W instead of 0.5 W as used for the above calculation.. at which it's maybe half as energy efficient as Bitcoin.

See here: http://blogs.wsj.com/digits/2014/08/15/german-startup-says-its-new-chip-halves-bitcoin-mining-energy/

So this would use half as much energy as a similarly sized Bitcoin network.

Here is my much longer analysis of the Nxt network: https://docs.google.com/document/d/1J8uhdshu9epGRrQHBaloGc4itdvuAHZDAUtNDjOhz-8/edit?usp=sharing

It's still a cool idea and hard drives are more reusable though..  idk.  I'll probably still buy a little but it's not as exciting as I was initially thinking unless he can figure out a way to use that data to store something instead of simply mine with it.


Btw, FakeAccount, you may want to read this article on RAM optimizers:
http://www.howtogeek.com/171424/why-memory-optimizers-and-ram-boosters-are-worse-than-useless/

Mining using user-submitted data would not work well. Miners would likely submit files made of deterministically generated data they could re-create when needed, and use those to mine with, turning it into POW. I noticed you linked the Permacoin paper a few pages back, which only gets around this problem by using a central authority to decide which files are able to be mined with.

Where this is more efficient, is for people mining with existing hardware they're also using for other purposes. The difference in power between 'normal usage' of a computer, and 'normal usage' + mining would be a much more interesting comparison.

[majere]

Actually, there is no plotter to plot only 1 scoop, but it is possible. Also, there is no miner. Again, possible.

It's not possible, because the whole chunk is shabal-ed & hashed as the last step of plotting.
Of course, it's possible to generate a full chunk, hash it, then throw away everything except one scoop.
And this is why CPU miner won't work well.

It's possible, however, to store scoops for some block ids, not all of them. I.e. store scoops for blocks 1-2000 on one HDD, 2000-4000 on another.

Or store info for every 10-th block, skipping blocks 1-9, making 10th block 10 times likely to find, but sleeping on other blocks. This requires a specialized plotter/miner. Maybe we're talking about the same thing in different words.

[majere]

BTW: I believe a top end i7 can do 7000 nonces/min, which, correct me if i'm worng, = 1.7gb/minute....but that don't sound right.....maybe it's 170mb...

7000 nonces * 64 bytes scoop = 448000 bytes = 437 kb / min
For 20 min block it's equivalent of 8.5 mb disk space. Uh oh. Is it really that slow?