Litecoin Core v0.10.1.2 Release Candidate! Check here
Is it still profitable to mine on a home computer?
expected_litecoins_per_day = your_hashrate_in_kH_per_s / difficulty * 0.0419
Current increase was around 16% the last two or three times, it will go up alot once BFL ships their asics but a well, just wait and see
Quote from: Sy on April 10, 2013, 03:14:06 PMCurrent increase was around 16% the last two or three times, it will go up alot once BFL ships their asics but a well, just wait and see Are you saying that just because BTC miners will switch to LTC if they don't have ASICs, or will their machines actually be able to do LTC also?
Your expected return, during a run of 2016 blocks (about 3 days) is:expected_return = 50 LTC/block * 24 blocks/hour * your_hashrate / network_hashrateTo be clear, this network hashrate is the software's estimate of the network hashrate over the course of the previous 2016-block run. It doesn't actually store that though, it stores "nBits", which is commonly reported as a floating-point difficulty number, such that:network_hashrate = difficulty * 2^32 / 150sso you can simplify that first equation down to:expected_litecoins_per_hour = your_hashrate_in_kH_per_s / difficulty * 0.0419or, to within 1%, expected_litecoins_per_day = your_hashrate_in_kH_per_s / difficultyAgain, this difficulty is nailed down at the start of each 2016-block run, and the equation holds for the rest of the run, regardless of changes to your hashrate during the run.So written this way, the trick is predicting future difficulty changes. The most direct way is to keep an eye on the block generation rate and run through the difficulty recalculation algorithm yourself, which is quite simple. At the end of each 2016-block streak, it looks at the time it took to generate all those blocks, and divides 2016 by it to work out the actual block generation rate, then adjusts the old difficulty linearly to compensate for the error. Effectively it picks a difficulty which would have made the previous 2016-block run complete in the right amount of time.For example, take the 153-difficulty sequence which ended this morning:Last block time: 2013-04-06 01:10:35Last block of previous run: 2013-04-03 10:39:05Total time for 2016 blocks: 3751.5 minutesAverage time per block: 1.86 minutesDrift factor: 2.5 / 1.86 = 1.34New difficulty: 1.34 * 153 = 205If you're running this calculation yourself before the end of a run, e.g. using the last 100 blocks as a guide, then make sure the sequence of blocks you use all have the same difficulty value (i.e. they don't cross a 2016-block boundary). You can use this calculation to get unstable short-term readings or more stable medium-term readings, depending how many blocks you look at. The best estimate for the next difficulty will come from using all of the blocks since the start of the current 2016-block run.In the end though statistics can help you find trends in past data, but guessing the future is up to the economists. Economics is about models, not truth, and there's no one correct model. So this is about as far as you can go with strict equations.The future network hash rate fluctuates according to profitability of mining; also bear in mind the time it takes a new miner to get equipped, which will cause some lag in the hash rate's response to exchange price fluctuations for example. There's also a varying degree to which miners pay attention to the true costs of their operations, e.g. power costs, whether it's worth running on obsolete hardware, whether they have the ready cash to upgrade, etc.And of course there's the predicted flood of bitcoin miners who may or may not switch to litecoin if ASICs lead to diminishing returns for them in the bitcoin market, and if litecoin's exchange rate stabilizes high.Then, what happens if the litecoin rate drops - will people stop mining? Or will they leave their rigs on anyway, now that they're set up, hoping for a future rise?There are lots of things you can model, and you really need to think about it before deciding which factors to include.
Page created in 0.226 seconds with 27 queries.