I realize that I am opening up my ideas to everyone, but the point of developing a cryptocurrency is not to get rich.  That's why we have mining and the developer is usually just one of the first to start.  What do you think about these possible BURST altcoins?  Keep the discussion in the Burst forum because it does not belong on this BitcoinTalk thread.  This post is only here because there are only a few that regularly visit the Burst forum and I will delete this post if someone on the Burst development team asks me.

https://burstforum.com/index.php?threads/potential-burst-altcoins.806/

I see that crowetic uses poolmining for a miner . . .

Possible bank idea (Sorry to make it so lengthy):
One major issue with a Burst bank is trusting the third party and determining the source of income for the interest because there are no loans by the bank.  It has been proposed that there are CD equivalent accounts where penalties for withdrawing early are used toward the interest rate.

My addition would be to use a pool as a bank.  A portion of the pool fee(slightly higher than normal fee to give a decent interest rate) would go toward interest and the normal rewards from mining would be diverted as deposits to an account owned by the trusted pool owner.  The length of the CD would be randomly chosen between a set amount of time to prevent mass withdrawals at once.  The penalty on withdrawals could scale down based on the time remaining in such a way that the penalty is 0% after 90% of the contract.  When the contract reaches completion, it would be automatically renewed for another randomly chosen amount of time (6-8 months?).  If someone decides to take a penalty and withdraw early, the additional funds would go toward a higher interest rate for that period. 

The trick part is securing the bank.  As catbref has already mentioned, removing public access to the wallet would help.  Even better, the funds should be sent to a separate account with a 2048+ character passphrase. Withdrawals are also difficult and I am sure could be done with smart contracts.  For security reasons, I think it would be better for the pool owner to make payouts manually.  The random interval on contract length would hopefully limit this number to about 10 per day.  Requests for payment could be made by PM on this forum, sending a message on the blockchain, or some other way.

Possible addition:
Owners with large amounts of BURST and almost no mining equipment could deposit money into the bank to earn interest.  This would take money away from the pool fee of legitimate miners, but it would encourage the whales (refers to size of wallet, not belt size) to keep their money longer for the interest.  In most cases, someone who bought a bunch of BURST without mining probably plans to do a mass dump in the future unless they have a reason to grow that amount (similar to POS with penalties or POSp?).  Potentially, the more BURST in the bank, the longer the contract length at the same interest rate.  This would force the whales to take a large penalty for mass dumping or grit their teeth with minor market fluctuations. 

As we have learned with any hacked exchange or accounts with large sums of money, security is the biggest concern.  It might even be necessary for the pool owner to have a separate account for every X (say 10) account holders or X% of total to reduce the security risk.  If one wallet is compromised, the attacker would not get as much and the funds could be covered by the pool owner. 

If someone picks up this idea, it would be nice if they gave me a small portion of their pool fee, but unfortunately not a requirement. 

Can you give a key for which miner each word relates to? The Blago miners are obvious with version number, but does poolmining refer to dcct's miner or a different one? A key would prevent future questions similar to this one.

I did not miss your message. I have been busy with other things and trying to port the optimizer GUI to linux (I know Java is supposed to be universal, but the GUI calls Windows commands).  I was also trying to speed up Blago's miner (unsuccessfully) and parallelize the optimizer code(writing to the same hard drive limits this and probably not possible unless writing to multiple hard drives at once  ). I wonder what language cryo is using for his complete GUI with plugins. C, C++, Java, Python, ...?

A couple pointers:
1. Is the file "Optimizer.exe" in the same folder as the GUI with the exact spelling as this post?
2. Does it load at all or crash when you press the Optimize button?

If you can answer these questions, it will help me narrow down the bug.

This run.bat file decided to stop running for me.  I made a couple changes and it works now.  I hope that is true for everyone.

I posted this a little while back, but it is a universal run.bat file that does not depend on what java version is installed.

Optimizing your plots will decrease the amount of time it takes to scan through all of them and potentially find a block before someone else.

An example:
It takes your computer 3 minutes to check all of the unoptimized plot files and you will have a deadline of 1 minute after 2.5 minutes of scanning.  Someone else may have a deadline of 2 minutes after 1.5 minutes of scanning.  The other person will get the block reward despite having a worse deadline because your deadline will never have a chance to submit.  You also won't know you missed a block because it will start scanning for the next block.  An optimized plot may find the deadline of 1 minute after 45 seconds of scanning and you would receive the block reward.  (Made the numbers up, but you get the idea)

To answer your question, it will speed up hashing in a matter of speaking, but in terms of hashrate as you think of BTC, then no, your overall "hashrate," or chance of finding a block, will not increase.  In the example above, you would eventually find the block either way assuming no one beats you to it, but an optimized plot would find it faster.

I also updated the plot optimizer with a GUI in the Burst forum:
https://burstforum.com/index.php?threads/plot-optimizer-gui-1-0-6.589/

Since I only know the basics of batch file commands, I did a search on Stack Overflow for an alternative method of launching the wallet that will not be affected by the version of Java installed. I found other solutions like scanning the registry for the version of Java and then running from that particular folder, but the solution below was less complicated. 

Using the FOR loop from http://stackoverflow.com/questions/638301/discover-from-a-batch-file-where-is-java-installed, I created the following bat file because I use Java 8 and uninstalled Java 7. It will search for java.exe and set a variable called JAVA_HOME. The command to start the wallet is the same as the original run.bat.  Feel free to test it out or if it does not work, I can post another solution that has worked for me. I added the first IF statement so the FOR loop would not run every time, but that IF may need to be removed if the batch file does not work after a Java update.  If you see something wrong, feel free to make the correction.

New comparison is BURST network at the popularity of Bitcoin right now vs. Bitcoin:
Bitcoin statistics stay the same as above.

BURST Electricity when an equal amount of money is invested (not including free hard drive space on the operating system drive):
Assumption: The average price of the Antminer S3+ costs about $350 since its release and runs at 450 GH/s.

284,772,770 / 450 = 632829 Antminer S3+ on the Bitcoin network
632829 * $350 = $221,490,150 (Actual amount is less considering how many ASICs are more efficient)

Assumption: A 3 TB hard drive costs $90.

$221,490,150 / $90 * 3 = 7,383,005 TB on network
Round up to 10,000,000 TB to account for hard drive space on the operating system partition.

10,000,000 TB * 10 W/TB = 100,000,000 W = 100,000 kilowatts

I rounded these numbers to give BURST the worst possible energy consumption. This is more of an estimate because it is really hard to know how much money has really gone into Bitcoin ASICs and figuring out how much space is added from C: partitions.

There are a lot of assumptions in these numbers, but it should still give a rough estimate.  

Bitcoin network electrical consumption:
Assumption: The average Bitcoin miner has the efficiency of an Antminer S4 of 0.69 Watts/(GH/s).

In reality, this assumption is very generous because the efficiency for most ASICs will be worse than one of the most power efficient available.  
Total Bitcoin hashrate as of 11/20/14 at 11:20pm: 284,772,770 GH/s

Total electricity consumption (at a minimum): 0.69 W/(GH/s) * (284,772,770 GH/s) = 196,493,211.3 Watts = 196,493 kilowatts


BURST network electrical consumption:
Assumption: The average hard drive on the BURST network is 1 TB.

According to http://www.buildcomputers.net/power-consumption-of-pc-components.html, the average hard drive consumes 10 W. Most hard drives on the network are probably 2 TB or larger, but assuming 1 TB is a worst cast scenario (two 1 TB hard drives use 20 W vs one 2 TB hard drive uses 10 W).

Assumption: BURST network is at its highest difficulty and largest size at 9000 TB.

10 W/drive * 9000 drives = 90,000 W = 90 kilowatts

90 / 196,493 = 0.045% of Bitcoin's electricity at current levels

EDIT: 10 W is the most that a hard drive typically uses. Idling uses about half as much power or less.

First and foremost, the option after -del should be 0 or 1, not 2. 0 = false and 1 = true. That could solve your problem because I have not had time to add error-checking.  

You should be fine on space if 17160993207923721836_6400000_4000000_40000 is the only plot file on your hard drive.  It takes about 1 TB and leaves about 1.7 TB free.  The optimizer will create the optimized file on the drive you specify before it deletes anything.  This means that you need enough space on your hard drive for both the optimized file and the original file unless you output to a second hard drive.  

I made a small mistake in the example bat file by specifying 3 GB for RAM.  It will actually use about 4x more RAM than what you specify due to how Windows works.  I may come back to this issue, but my attempt to fix it last time was causing a memory leak (that version was never released).  Make sure you adjust the memory usage accordingly for your system.  I recommend 1-1.5g for the standard 8 GB of RAM on desktops.

Since I started using Blago's miner (good work by the way), I noticed that memory usage stays around the same amount even when not actively looking for a block.  This basically negates the purpose of the delay function and should be taken into account when optimizing.


As a heads up, IGNORE all of timk225's postings from now on.  If you look at his previous posts, you will notice that he is trolling the forums.  I know these types of people and how they look forward to people's reactions.  If you see someone make a comment to one of his posts, remind them to keep ignoring him.  Specifcally, he seems to like trolling mostly on Burst and Cryptcoin.  This implies that these coins have an active community and give a desired response in the shortest amount of time.  If he truly believes that cryptocoins are not going anywhere, then he is in the wrong forum.

"Darker" can be swapped out for "more anonymous." I never really looked into the workings of Darkcoin to know its details.

I also started with "algorithms" instead of "rounds," but BURST uses 4098 rounds of the same algo versus 11 rounds of different algos. This makes the comparison indirect, but the point is that an ASIC would probably need a lot of parallel(GPU-like) cores versus the 11 sequential (CPU-like) cores needed for X11. I need a little clarification on this point. BURST uses 4098 rounds per nonce or 4098 rounds per plot? From past posts, I think it is 4098 rounds per nonce.

What about this?

X11 uses 11 rounds,
      X13 uses 13 rounds,
            X15 uses 15 rounds,
                  X17 uses 17 rounds,
                        BURST uses 4098 rounds!

372 times darker than Darkcoin and 20x more energy efficient (assuming a 200W GPU and a 10W hard drive).

ASIC Resistant:
A BURST ASIC would require 4098 more cores/threads than today's Scrypt ASICs and draw MUCH more power.

Can someone confirm if some or all of these facts as true?

4098 / 11 = 372

Blago, I have a feature request for your miner.  Can the program create a text file (or .csv file) that contains only the line with the best deadlines for each row?  

From your last post, it appears that the best deadline is the only one submitted.  This means that the code can write to the text file right after submission or if necessary, while it is on the same block, keep appending to the same line until the block changes.  Since not all blocks reach 100% scan, some deadlines may not be written, but that would be fine for the file's purpose.  

The reason for the text file is to allow users to load it in Excel and get important statistics like average deadline and standard deviation.  From this information, the community can piece together an approximate payout per pool for a certain plotting size range(1-2 TB, 2-5 TB, etc.).  A size range is needed because most of the pools give shares based on an exponential formula and an average burst per TB for each pool would vary based on total plotted size.  Each pool has its own formula and the complaints to go with it. This new feature may help the pool devs refine their formulas and give the community a better idea of which pool to mine on.  I see a non-writable (except for the creator and a select few) Google Docs file with the statistics of the community from posts on this forum (assuming they back up their numbers with Excel chart pictures).


FakeAccount, your plots should be fine since my plots seem to work.  What I found was throwing off my deadlines was my system clock.  After syncing it manually to internet time, my deadlines got much better and this leads to my other feature request.  My system clock is really bad at keeping time despite changing the battery on the motherboard about a year ago.  My solution was to download a program here: http://www.worldtimeserver.com/atomic-clock/.  I have been varying my update interval between 10 minutes and 1 hour.  Unfortunately, syncing while the miner is looking for a block seems to be a bad idea and ruins my deadline for that block (although I have no proof of this except some blocks with a best deadline of thousands of days).  

My second proposed feature is to make an option for the miner to try syncing the system clock between blocks.  The two issues that I can see with this possible feature is that a program requires admin access to sync the clock and the other issue is if a new block happens to begin at the same moment that it is syncing.  For these reasons, the default option would have to be off.  Alternatively, I will keep using the program that I have been using already.  

On a side note, cryo's newest GPU plotter creates optimized plots if using the direct writing option.  Don't freak out if the progress stays at 0% for a while because it will start updating the progress once the plot file size reaches the output size.  Cryo will probably fix this in a future update once he bases the initial progress meter on the size of the file before basing the meter on the number of scoops plotted *hint hint to cryo.

I am glad to hear it is working now. 1.6 was only a small update to prevent deleting and the plot file should not be any different from the previous versions.

Plot Optimizer v1.6

Per FakeAccount's suggestion, I have added an option to not delete the original plot file. When I have more time, I will organize the order of the parameter list better. The new option is used with a -del 1 to delete the original file or -del 0 to keep the original file and is placed before the memory used option. If you do not include a -del parameter, the default will delete the original file.

Download Link:
http://bitshare.com/?f=epn02ow4

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.

I faced the same dilemma recently. First, I bought a USB 3.0 external Seagate hard drive. With an ambient room temperature average around 80-85F, the hard drive runs at 112F (~44C). Honestly, anything over 100F is too hot and killing the life of the hard drive. My new method involved getting 2 of these: http://www.newegg.com/Product/Product.aspx?Item=N82E16817182245&cm_re=rosewill_enclosure-_-17-182-245-_-Product as Shell Shockers at $20 (now $22) and two of these: http://www.newegg.com/Product/Product.aspx?Item=N82E16822145911. As NAS drives, they can handle higher temperatures and made to run 24/7 (I believe Seagate externals over 3TB run less than 7200 RPM). With the variable fan speed on the enclosures, they have never exceeded 100F.  This is the slightly more expensive method, but should improve hard drive lifespans. Most external drives do not have NAS drives in them.

Another method is this not so crazy expensive rack for $30: http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=4173135&CatId=4269. Connecting all of the hard drives to your motherboard could pose a major problem since most cases do not have 5 ESata ports (assuming you have SATA to ESATA conversion).

Lastly, assuming you have more SATA ports available on your motherboard, you can convert unused 5.25" drive bays into a hard drive rack.  The best ones convert 2 bays into 3 hard drive slots or 3 bays into 4 hard drive slots with a fan in front to keep it all cool.

You are right. Thank you for reminding me. I forgot about the network speed bottleneck.

I like your idea of dynamic Storj. Instead of being forced into giving 100% of your available space to one specific coin, you could modulate the amount to each coin. To minimize stress to hard drives, it would probably be in 100GB increments or larger for the slider if BURST is programmed into Driveshare. Otherwise, it would be automatic as you suggested. Keep up the brainstorming!

I have a possible second use for storj/BURST.  It won't be an issue initially, but eventually, like almost every other cryptocurrency, storj may be faced with very low profitability as selling exceeds buying.  The solution will be to swap Driveshare space for plot files when BURST is more profitable.  As people switch over and the selling pressure gets too high, then they can switch back to storj until BURST improves (buys catch up to sells).  I can easily see a BURST miner/Driveshare auto-switching program.  By that time, optimized plot files should be easy to generate in a short amount of time to make this possible.

It all depends on how the numbers line up.  It is still too early to tell what will happen, but as a warning to the storj developer, a good chunk of your network may fill with a lot of plot files and will hopefully not bottleneck overall network space too much for actual files (won't be an issue at least for a while).  On the flip side, BURST and storj may help relieve the other one of some of the selling pressure that is bound to happen and possibly help increase the number of buys as the two gain popularity together.