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

12hrs mining, 1TB, ~50 BURST payout.  Take into account large difficulty fluctuations lately, typical variation.  Sounds about right.  Maybe mining for 48-72 hrs and then seeing what your average payout is would be a good idea before coming with the F-bombs.  Just saying 12hrs seems like a short amount of time to come up with such a response.

Either way,  Good-Luck

Hello Dev,

Just a quick question.

To better deal with the block time variation issue would it be possible to give the winning deadline to the submission that is closest to 4min instead of the submission that is the lowest deadline?

*edited for details*
The network already knows who has the lowest deadline.  This option would just require the network to know who has the deadline closest to 0, where deadline submitted = ( | 4min - Miner_submission | )

** edited again***
But, how long would the network wait for a submission that was closest to 4min? Right now the network just waits until the time has past for the lowest submission.  Sorry I'm thinking out loud through the forum.  I'll be quite now

*shrugs*

Just a thought.
Keep up the good work.

Looks good!
Linux / Windows?
Available or only for you?
node?

I did wait 4 blocks, but it only happen in 5 blocks 

after a change of the reward recipend, you have to wait 4 block to take affect.

Problem solved after 5 blocks, I can't wait to try the new pool, haha

I have set reward assignment to BURST-BANK-DT2R-BM8G-FYFRH, and getting error message:-

{"errorCode":1004,"errorDescription":"Your Burst account does not have pool's account as reward recipient."}

This error occurred in both uray miner and blago miner. Any clue? Or it is not open to public yet?

Not sure if this has been looked into, but compression could compromise PoC in the future. I assume plots are made in such a way that they'd be uncompressible, but if a specific algo is developed for compressing them, it could lead to CPU races, where people would need more powerful CPUs to mine more.

This proofs you are the best dev around. Excellent answer! ***applause***

Soon I gonna call you Nick 

This PoC2 sounds very interesting!  I'll have to comb through the new pages more carefully so I don't miss any updates/infos about it in the future!  As always, keep up the great work Dev!

Yep it's mine, thanks for the donation

So far there are no known attacks, however there are a few weaknesses, although some of them can be solved with an updated algorithm.

1. Not much at stake.
Many people consider the ability to mine multiple chains at the same time without a significant increase in resource consumption to be a major weakness in PoS algorithms, and this would apply partially to PoC as well. In PoC you could mine multiple chains at once, although do to disk bandwidth limits you would be able to mine significantly less chains than you would with PoS as you would be reading different parts for each chain, and therefore electricity consumption would also increase from doing so. This puts it in between PoW and PoS, although much closer to PoS in the 'nothing at stake' argument.

2. Block verification cost
The strategy of hashing the nonce and account many times in advance and saving the result may result in a constant low computational cost for checking the nonce later, but everyone else still needs to run the whole hashing cycle on that nonce to verify the block. This results in very high computational cost for verifying blocks, and blockchain syncing being cpu bound.

3. Inability to scale to higher processing power
Over the life of bitcoin, hashrate improvements have been much more significant than improvements in hdd capacity. The amount of work added in advance in PoC is constant, so if a similar arms race was to occur, significant enough processing power advances could cause PoW mining to become more efficient than mining PoC as intended. One user ran some calculation trying to estimate how the most efficient sha256 asics would compare in efficiency to hdd mining. Although the calculations were flawed, as they assumed 1 sha256 hash == 1 shabal256 hash regardless of the number of rounds done for the hash, if adjusted to assume 1 round of sha256 == 1 round of shabal256 they estimated those asics would have about 2x the efficiency of using hdds. Although having it within the same order of magnitude isn't too bad, and wouldn't provide enough of an incentive to actually design the hardware, it does show that it may already be possible to achieve better efficiency that way, and the gap could widen in the future.

4. Higher PoW resistance requires higher portion of data being read
Under the current PoC system, increasing the number of scoops(which would decrease the amount of data read each block) would also decrease the effective hashrate/TB, however the hashrate from trying to mine it PoW style would be unaffected. This is a bad trend as reading higher portions of the disk each block provides higher PoW resistance, which is also worse for HDD life.

5. High blocktime variance
Due to the high amount of diskspace used per nonce, the total amount of nonces checked per block is very low compared to PoW coins. This leads to higher variance in block times.

And this is why we need PoC2.

PoC2 has only been mentioned a few times publicly, but is a second hdd mining algorithm I plan to add in addition to the original POC. The original PoC will continue to remain as long as problems related to it don't start. PoC2 should solve points 2-4 above. A (very slow) miner for it was hacked together for it a few weeks ago, although it has not yet been implemented in the client.

PoC2 started on irc some time ago during a discussion about the block verification cost, mczarnek posed the question about whether plots could be generated similarly to how PoW mining works, so verification would be just comparing a hash to a target. The end result of this once thought out was that plot files could store nonces instead of hashes, and there would be constraints on the nonces that could be used, so you'd be storing allowed nonces. When mining, you would only be able to use nonces where hash(account concat nonce) < target, and hash(hash(account concat nonce)) mod totalscoops == currentscoop. Plotting would then be similar to PoW mining for that target, and then sorting the results into buckets based on the second hash. The appropriate bucket could then be read each block and network state, account id, and nonce could then just be hashed together looking for the lowest result.

2. Block verification cost
Verification would be cheap. 1 hash would be needed to compare to the target, another would be needed to calculate the scoop, and a third would be needed to check the deadline.

3. Processing power scaling
The target can be set to slowly decrease over time. Although this would change the current rule that you never have to re-plot, users would able to plot setting the target knowing how long the plot would be usable for. Both mining with the finished plots and verifying the blocks would remain constant cost regardless of the target. As plotting and PoW style mining would become harder over time it would help prevent gains in processing power from causing PoW to become more efficient.

4. Under PoC2, changing the amount of scoops also directly affects PoW mining hashrate the same way. This allows it to be scaled to higher or lower portions of the disk being read each block without decreasing PoW resistance. Initial testing showed that storing nonces as 4 byte differences between the previous one in each bucket should be doable, which if the scoop number was adjusted to have PoC and PoC2 have the same hashrate/space used would require only 16MB/TB/block to be read, instead of the current 256MB/TB/block. A scaling factor could also be applied to the base difficulty to lower that even further, however it would make variance even worse.

Great work today, guys Quite a bit has been done even if it doesn't is apparent yet. 

Is that your picture in the article? I like it!

Please re-tweet it too! HERE /url]

Thanks If you planning to write some more, let us know. We need writers in the PR team 

Go right ahead!

Nice work! Is it ok if I tweet about your article? Will send you a donation too

I wrote this article on Burst a while back on my blog, what do you think about it? http://razorsforex.blogspot.com/2014/12/burst-cryptocurrency-minable-with-your.html

I can prob whip up another one on ASIC resistance. Or maybe add to the existing article.

Donations -> BURST-3DZV-X67N-3K9S-G3XK7

It's all good, people blame me regardless. lol. xD

Can someone write a good tweet about/explaining BURST's ASIC Resistance (max 140 char)?

5,000 BURST to the one we chose!

Email [email protected] with your contribution.