As BTC has the highest difficulty of any coin you will mine, if you want to mine BTC + any other coin the difficulty will need to match BTC, and when matching BTC will match any merged coin with a lower difficulty....
No the others will mine before So your saying that all accepted shares will be submitted to every coin? I thought only shares that met the BTC block criteria were submitted to merged coins? All submitted shares are tried on every coin you're mining. It is the beauty of merged mining. What might not solve your BTC block may very well solve some other coin. That's how I've been donating FSC. I merge mine it with IXC, NMC, DVC, etc. the difficulty of FSC was obscenely low so I was finding over 100 blocks a day. |
|
|
|
|
Hunterbunter, great job on that tool. Thanks for taking the time to create it.
A number of us who run our own nodes have committed to donating the proceeds received from merged mining to p2pool miners. So far, mdude77 has been the only one of us who's node found a block of BTC. He setup a number of donation wallets for the merge-mined coins to which anyone can deposit. He converts the NMC/IXC/DVC/FSC/I0C to BTC and then donates back to the pool. Your tool has made it far more visible and a ton easier for others to directly donate BTC now, as well.
|
|
|
|
Can someone use p2pool to solo mine and merge mine at the same time?
So mainly is there an option to turn btc solo mining on?
If not - would mainly mine other coin e.g. IXC and merge mine BTC offer the same result?
I imagine you could... you'd have to hack the code a bit (there's a guide on how to do it here: https://bitcointalk.org/index.php?topic=512042.0. Then you'd just start up p2pool as you normally would for merged mining. Remember, though, since merged mining is solo mining, you're now solo mining everything. Maybe you get lucky and hit the lottery by generating the BTC block. |
|
|
|
I hate to bring up CEX.IO, but at least you can sell or trade back your hash. Yeah, the evil empire  . I agree, though, it's a great idea they implemented allowing you to trade your hashing power. |
|
|
|
@johnnybravo I don't see static anywhere, do you? Difficulty History Date Difficulty Change Hash Rate
Jun 05 2014 11,756,551,917 12.44% 84,156,677 GH/s
May 24 2014 10,455,720,138 18.10% 74,844,960 GH/s
May 12 2014 8,853,416,309 10.66% 63,375,223 GH/s
Apr 29 2014 8,000,872,136 14.64% 57,272,474 GH/s
Apr 17 2014 6,978,842,650 14.04% 49,956,502 GH/s
Apr 05 2014 6,119,726,089 22.23% 43,806,706 GH/s
Mar 24 2014 5,006,860,589 17.80% 35,840,504 GH/s
Mar 13 2014 4,250,217,920 11.39% 30,424,245 GH/s
Feb 28 2014 3,815,723,799 21.92% 27,314,015 GH/s
Feb 17 2014 3,129,573,175 19.39% 22,402,357 GH/s
Feb 05 2014 2,621,404,453 19.49% 18,764,744 GH/s
Jan 24 2014 2,193,847,870 22.59% 15,704,175 GH/s
Jan 13 2014 1,789,546,951 26.16% 12,810,076 GH/s
Jan 02 2014 1,418,481,395 20.12% 10,153,885 GH/s
Dec 21 2013 1,180,923,195 30.01% 8,453,378 GH/s
Dec 10 2013 908,350,862 28.41% 6,502,229 GH/s
Nov 29 2013 707,408,283 16.07% 5,063,826 GH/s
Nov 17 2013 609,482,680 19.29% 4,362,847 GH/s
Nov 05 2013 510,929,738 30.70% 3,657,378 GH/s
Oct 26 2013 390,928,788 46.02% 2,798,377 GH/s
Oct 16 2013 267,731,249 41.45% 1,916,495 GH/s
Oct 06 2013 189,281,249 27.19% 1,354,928 GH/s
Sep 25 2013 148,819,200 32.13% 1,065,289 GH/s
Sep 14 2013 112,628,549 29.56% 806,227 GH/s
Sep 04 2013 86,933,018 32.22% 622,291 GH/s
Aug 24 2013 65,750,060 29.40% 470,657 GH/s
Aug 13 2013 50,810,339 35.88% 363,715 GH/s
Aug 03 2013 37,392,766 19.63% 267,668 GH/s
Jul 22 2013 31,256,961 19.47% 223,746 GH/s
Jul 11 2013 26,162,876 22.63% 187,281 GH/s
Jun 29 2013 21,335,329 10.32% 152,724 GH/s
Jun 16 2013 19,339,258 23.92% 138,436 GH/s
Jun 05 2013 15,605,633 28.41% 111,709 GH/s
May 25 2013 12,153,412 8.64% 86,998 GH/s
May 12 2013 11,187,257 11.03% 80,082 GH/s
Apr 30 2013 10,076,293 12.28% 72,129 GH/s
Apr 17 2013 8,974,296 16.96% 64,241 GH/s
Apr 05 2013 7,673,000 14.59% 54,925 GH/s
Mar 24 2013 6,695,826 38.13% 47,931 GH/s
Mar 14 2013 4,847,647 10.98% 34,701 GH/s
Mar 01 2013 4,367,876 19.63% 31,266 GH/s
Feb 18 2013 3,651,012 11.47% 26,135 GH/s
Feb 05 2013 3,275,465 10.33% 23,447 GH/s
Jan 23 2013 2,968,775 -8.64% 21,251 GH/s
Jan 08 2013 3,249,550 9.06% 23,261 GH/s
Dec 26 2012 2,979,637 -11.59% 21,329 GH/s
Dec 10 2012 3,370,182 -2.00% 24,125 GH/s
Nov 26 2012 3,438,909 2.08% 24,617 GH/s
Nov 12 2012 3,368,767 1.95% 24,115 GH/s Nope... never once did I state that I believed it would remain static, or that it had. I simply provided proof that your statement of "under no conditions" was incorrect. I certainly don't believe it will remain static simply because more hashing power is constantly added to the network. But, that's back to my statement on risk. If I were to invest 4 BTC in mining gear, I am hopeful that said gear will return me back more than that 4 BTC. If the difficulty increases at ~15%, I won't make it. If it is 10% I will. If I invest $2599 on a contract, I am hopeful that at the end of the year, the BTC I have earned can be converted into USD with a value of more than $2599. Maybe I can explain this in a different way: I make three investments. Investment 1 is to purchase 4 BTC at $2599. Investment 2 is to purchase a 1TH/s mining contract for $2599. Investment 3 is to purchase that same 1TH/s mining contract for 4 BTC. For investment 1, I am hopeful that the price of BTC increases and after a year, I can sell them for profit. For investment 2, I am hopeful that my contract has earned me enough BTC to sell for more than the $2599 I initially invested. For investment 3, I am hopeful that my contract has earned me more than the 4 BTC. This one is the "I gave some guy 4 gold bars and hoped he gives me back more than 4 at the end." One needs to evaluate the risks and make a choice. Your assessment, if I read it correctly, is that investment 3 is a fool's errand. Others might state, "Gee, I don't think BTC is going to see >10% increases from this point forward, so let's go with investment 3." If you've spent time going through my posts throughout the forums here, you'll know that I have invested in hardware. I made that decision for two reasons. First, is because I believe in BTC, and I wish to contribute to its success. I mine, and I do so on p2pool. The second reason, and one that is not so altruistic, is that I hope to make a profit while supporting BTC. My personal opinion is that cloud hashing is slanted in favor of the company providing the hosting. As someone else wrote in another post, "Why would they sell you $1 for $0.75?" Companies providing cloud hosting have evaluated the risks/rewards and it is their stance that they will make more by selling hashing power to you and me than they would just hashing for themselves. |
|
|
|
Since when does difficulty stay still? I actually anticipate a massive spike once Asicminer puts their 15 PH on the network.
You're using the wrong calculators dude, no way you'll mine 15.622 BTC under any conditions.
Um... simple math: Difficulty * 2**32 / hashrate / 86400 = number of days to find a block. 25 / number of days to find a block = expected earnings per day. Expected earnings per day * 365 = total BTC earned over a year. 11756551917 * 2**32 / 1000000000000 / 86400 = 584.42136571
25 / 584.42136571 = .04277735
.04277735 * 365 = 15.6137344
So, yes, assuming static difficulty, you will indeed earn that amount. If you anticipate a 10% increase in difficulty, then you repeat that formula 26 times (assuming a 2 week difficulty change - this one I'll give you is variant because of reliance upon 2016 blocks, rather than actual time). You always calculate with BTC invest in, never fiat.
If you invested 4 BTC, you ROI by making back 4 BTC plus, not what 4 BTC's fiat amount was worth when you invested.
That's like saying I paid 4 gold bars for this house, but the house tripled in value, so the 1.33 gold bars I made back is A-OK. Uh, no it's not, you just lost nearly 3 gold bars.
Your example is wrong. You're converting gold bars into a house. The example would be better had you said, "I gave a guy 4 gold bars hoping that after a year he would return me more than 4 bars." |
|
|
|
Mining have nothing to do with the btc/usd price ratio. You should always report mining only to btc.
I understand what do you mean so we must stick in BTC for mining report, not USDif we do like that, hard to make ROI in 3 months, maybe 4-5 months still possible That is exactly it. You always calculate in BTC (invest) to BTC (mining profit). If you're mining (hardware or cloud) hoping USD rise, but with a risk of not making as much BTC as you put in, you're losing money plain and simple. If you invest in USD, but are also hoping for a BTC price increase, you're better off just buying the Bitcoin outright and sitting on it. You're always taking a risk, which is what my initial statement was. Regardless of if you invest USD, EUR, YEN or BTC, you hope that the output will be greater than your input. If you invest 4 BTC now, you're hoping that difficulty doesn't rise so dramatically as to make it impossible to recover that 4 BTC. If you invest $2599 now, you're hoping that the amount of BTC you earn from mining ends up greater than the $2599 you put in. |
|
|
|
Yes, but I find it very hard to belive that you don't know that this difficulty is increasing every 11 days (between 12% - 20%). Your calculations are misleading because you know very well what I'm talking about. It's not good for the image of your company to state false numbers, the difficulty it's not static. Present all the risks with buying cloud mining contracts so the costumers can make their calculations . Don't mislead costumers with false calculations, we had enought companies like this! It's not just the difficulty that changes. The price of BTC also changes. Sorry, $2.6 per GH/s is just not competitively priced at all. No ROI for customer at all locked in for a year, only profit for provider and that's it.
Gotta be much lower than $2 per GH to even be considered.
It's all variables and it's all risk. Whether or not you choose to accept it is the question. You can't just make a blanket statement of "if it's not under $2 per GH, it'll never ROI." If the price of BTC shoots up to $1000 tomorrow, that $2 per GH will ROI just fine. Not if you pay in BTC, it won't. If you pay 4 BTC, you'll never mine back 4 BTC under any conditions, whatsoever. So my blanket statement does apply. No, your statement was using USD "...lower than $2 per GH to even be considered". If you pay a current price of $2.60, which is the asking price of the contract, that's your starting point. if BTC crashes to $100 and stays there, you'll never recover your initial investment. If BTC goes to $1000, you're going to make your investment back and then some. Your next statement, "...you'll never mine back 4 BTC under any conditions..." is incorrect. If difficulty were to remain a constant, at current difficulty you'll mine 15.622 BTC in a year. Projecting a 10% difficulty increase will net you ~6 BTC. |
|
|
|
|
Ooooh.... exciting! I'm pulling up a seat. Beer and nachos, check. Let the games begin!
|
|
|
|
Yes, but I find it very hard to belive that you don't know that this difficulty is increasing every 11 days (between 12% - 20%). Your calculations are misleading because you know very well what I'm talking about. It's not good for the image of your company to state false numbers, the difficulty it's not static. Present all the risks with buying cloud mining contracts so the costumers can make their calculations . Don't mislead costumers with false calculations, we had enought companies like this! It's not just the difficulty that changes. The price of BTC also changes. Sorry, $2.6 per GH/s is just not competitively priced at all. No ROI for customer at all locked in for a year, only profit for provider and that's it.
Gotta be much lower than $2 per GH to even be considered.
It's all variables and it's all risk. Whether or not you choose to accept it is the question. You can't just make a blanket statement of "if it's not under $2 per GH, it'll never ROI." If the price of BTC shoots up to $1000 tomorrow, that $2 per GH will ROI just fine. |
|
|
|
Hmm, die Dummen sterben nicht aus und ihr lebt davon...  I don't speak German, but from Google Translate, it appears to be some form of the saying, "There's a fool born every minute". |
|
|
|
Ummm... I can see how you might have missed it, though. There was a bunch of other stuff going on regarding CBCM and SP-Tech. Zvi, I really like the disclaimer at the end of your post  If you create a file called /etc/mg_ignore_110_fcc the FW will not limit the 1100W. Note that this mode of work is not well tested by me, and can cause extreme heat in some cables. Make sure you have proper cables that match the amperage of the system. We take no responsibility of any damage done to the miner, PSU or your house if you set this flag. The PSU supports up to 14.5 Amper, so make the proper computation (and don't forget to add 10% to SP10 limit for PSU efficiency). Here's a way to disable the safety measures we put in place. Don't blame us if you burn down your house  |
|
|
|
$2599 for 1TH/s for a year. Did I read that correctly? That price is surprisingly competitive. I'm not one for cloud hashing, and in fact have steered others away from it in general; however, this price is basically the same as purchasing your own hardware. You don't have to deal with the electricity/maintenance, either. |
|
|
|
Actually, I hadn't thought about discounting orphans, since they again could potentially solve the BTC requirements. As an aside, can anyone clarify exactly what http://mining.coincadence.com:9332/rate is reporting? from web.py: web_root.putChild('rate', WebInterface(lambda: p2pool_data.get_pool_attempts_per_second(node.tracker, node.best_share_var.value, decent_height())/(1-p2pool_data.get_average_stale_prop(node.tracker, node.best_share_var.value, decent_height()))))I was about to reply that it's just calculating the overall hash rate of the p2pool network, but that little bit about the "get_average_stale_prop" threw me off. I'd have to dig further into the code to answer you more accurately. If I get the time tomorrow, I'll try to get back to you on it. Hopefully someone more familiar with that could answer it sooner. |
|
|
|
|
I think his last post stated that he was working late shifts this week and was trying to set something up still. It'd be great to have the first-hand account / impression.
|
|
|
|
They've got a signed letter from Spondoolies-Tech attached to their prospectus, wherein Guy clearly states that they will have 35 SP-10s for round 1, and the subsequent 7 rounds will be confirmed/supplied dependent upon existing stock. So, assuming these guys actually are successful in raising the BTC for their first round, they've got 35 SP-10s set aside for them. This is, of course, if they're legit and didn't forge the letter |
|
|
|
For the luck calculations I'm considering using "pool_nonstale_hash_rate" from "global_stats", while at first look it seems like I'm cherry picking the best data to shine a good light on p2pool, with pool orphan+DOA rates often touching 20% I feel like including them in the luck calculation could significantly throw things off, so I want to base luck on actual valid work... Open to feedback on this one. You're cherry picking, but remember, those DOA shares could potentially still be solutions for the BTC block chain. I think you'd be doing the calculations a disservice by not including the DOA, since that hashing does indeed add value. However, unless I'm missing something obvious, p2pool does not publicly expose its version of the blockchain, which makes it difficult to determine submitted shares by miner for miners who are not on my node. No, there is no "sharechain.info" site as far as I know. However, by running the node, you have a complete copy of the share chain. You can use the information in there to calculate how many shares each address has submitted across the network. You're still bound by the limitations I pointed out (excessive luck - both good and bad) which would affect the calculations. Honestly, though, your method of using percentage of expected block payout to then determine the approximate hash rate of that address will probably get you a relatively close approximation. Close enough for government work, anyway... which about the best you could hope for here since there's no way to actually accurately garner this information. I'm going to test my original proposal, basing the estimated hash rate on the per-miner payout from the last found block and see how accurate it looks based on miners on my node with known hash rates (I'm already collecting/storing this data so it wont bloat the DB, and requires less new code). I emphasized that because it's a pretty important point. Your node only approximates the miners' true hash rates based upon shares it receives from those miners. The value can swing pretty wildly, especially if you've got a wide range of hashing power. This is where setting the pseudo-diff comes in to play. If all of your miners actually set an appropriate value, then you'd get a better approximation. Of course, you could always throw in the auto worker diff patch, which would dynamically assign difficulties to each worker, instead of having difficulty assigned based on the node's hash rate. Again, though, these are approximations, but we're back to the government work again I think you're doing a fantastic job with your site. Keep up the great work. |
|
|
|
Alternative p2pool.info Suggestions:I'm working on getting this live this week. I plan to try and reproduce all the data from the original, and include some other stuff we are already storing. I've looked over the p2pool.info Azure code (not something I am familiar with) and have decided that it will be faster to write my own version on a LAMP stack as that is already the foundation of the Coin Cadence site. As you might expect there are already some substantial differences between Coin Cadence and p2pool.info as to what and how p2pool data is stored and collected. The biggest change/advantage of my version will be the fact that all data is gathered locally from p2pool and bitcoind compared with the current p2pool.info implementation which pulls block data from blockchain.info I have a few questions for the community as a whole as to how to calculate and present some of the stats: Estimated time to block: This is currently calculated on the fly by p2pool using the pool hash rate and "attempts_to_block" from: http://mining.coincadence.com:9332/local_stats attempts_to_block=
parseInt(local_stats.attempts_to_block || 0);
time_to_block= attempts_to_block / pool_hash_rate;
$('#expected_time_to_block').text((''+time_to_block).formatSeconds());
The problem I see is when to store this value in the DB. The pool hash rate fluctuates pretty wildly even when miners are relatively consistent, this is a fact of life when trying to calculate the global rate of the distributed pool. Add the fact that miners are joining and leaving p2pool on a regular basis and it becomes even more complicated. Should the expected time to block be stored immediately after or before a block is found? Should it be stored every x minutes and an average calculated on a per block basis? Very open to suggestions! Pool Luck:Assuming we have decided on a satisfactory answer to storing the expected time to block above, this is pretty straight forward... The question is how the luck stats are presented. In the current p2pool.info implementation luck is presented as a % over the last 7, 30 and 90 days. I'm considering 2 alternatives: 1. Borrowing Slush's time frame and using 1, 7 and 30 days. 2. Basing it on blocks rather then time, i.e. current block luck, last 5 blocks, last 15 blocks, etc... What do you think? Estimated Hashrate:in current p2pool.info implementation: The following users / addresses have submitted at least 1 valid share in the past 24 hours. Note: Hashrates are very rough estimates based on the number of shares submitted in the past day. They may be off by 10-20% or more due to variance. This uses some fuzzy math that I don't fully understand. If anyone has a method of calculating this and can explain it to me I'd love to hear it.... Here is my proposed solution, and to be honest I'm not sure if it is better or worse then the current implementation, and am very open to suggestions: Using data provided by p2pool here: http://mining.coincadence.com:9332/current_payoutsRetrieve the following: current total block payout (including tx fees), payout per miner, global pool hashrate Calculate miner % of total expected block payout. Miner estimated hash rate = % of global pool speed based on % of expected payout?? So for example if a miner has 10% of the expected total payout, we can assume they have 10% of the global hash rate... Again, fuzzy math at best and am open to suggestions.... SummaryI'd like feedback on my 3 suggested methods: 1. When to store estimated time to block (every x minutes and use average, just before or just after a block is found) 2. Calculating/Display format for pool luck 3. Estimating miner hash rates Thanks! Hey windpath, You can always calculate the expected time to block. I'm not sure why they use the formula "attempts / rate". Expected time to block is based on the following: Difficulty * 2**32 / hashrate / 86400 = number of days to find a block As you can see, that value is going to fluctuate considerably based on hash rate. One minute it could be 1.2 days, and the next 0.5 days. This actually happened just a few days ago when one minute the pool reported about 500TH/s and the next it reported just over 1PH/s. I guess what I'm stating is that the best you can hope for providing is an "average" value. Collect expected time to block values every X units of time. You can't just use either just before, or just after the block is found. This will impact your luck calculations as well. The constant in that equation is the time between blocks. Since they are timestamped, you know exactly how long it took. Then, depending on how many "expected time to block" values you've recorded, you can make an educated guess on the luck. By the way, you'd have to start your stats collection immediately after p2pool finds a block for the most "accurate" calculations. The reason the other calculations are so far off is because they are all based on submitted shares. That's your "fuzzy math". Your miners know their own hashing rate. Why? Because every single work unit is considered. The pool does not, because not every work unit is considered. It's an estimate based upon how much work of a given value is submitted. Therefore, while extremely unlikely, it is entirely possible that a miner with 1GH/s submits 100 shares in a minute. The pool would report that miner having a substantially higher hash rate that it actually does because of it. Unfortunately, that's what we're stuck with. Using a variation of the formula I gave above, you can estimate the miner's hash rate, since you know all of the other variables. Let's use my example of the miner submitting 100 shares in a minute. For simplicity's sake, we're going to make the assumption that those 100 shares were all that were submitted in a 24 hour period. 100 shares in 24 hours = 864 seconds to find a share.
Current share difficulty = 1508968.56
1508968.56 * 2**32 / hashrate = 864
hashrate = 7501123398023.39555555555556 hashes per second = 7.5TH/s So, the miner is actually a 1GH/s unit, but p2pool thinks it's 7.5TH/s. Obviously, this is a contrived example to display the effect of a miner not falling within expected parameters. However, looking at the expected payouts, you would think this miner is in reality 7.5TH/s. Alright, I've rambled on long enough and should probably get back to work |
|
|
|
I was just wondering if anyone ever found a BTC block with less than 10 GH/s. I know that's nearly impossible to find a BTC block. It's like playin the lottery Have I found a block with my U2s? Nope. Am I trying? You bet. I solo mine with my 5 U2s. Running on a Raspberry Pi, there's virtually no cost. Best share I've seen on one of them? 98 million. |
|
|
|
Daily payments received to date (200 gh/s contract) :
0.00867347 BTC - 4/6/14
0.00874600 BTC - 5/6/14
0.00829127 BTC - 6/614
0.00853379 BTC - 7/6/14
0.00848623 BTC - 8/6/14
0.00875721 BTC - 9/6/14
Todays payment 10/6/14 0.00799016 BTC Mining rewards took quite a hit today didnt they? Depends on what pool MT is actually pointing it's hashing to. The larger pools would have less variance, and the payouts would be more consistent. That's actually a good question - and maybe one that has been answered elsewhere. Do we know on which pool MT's cloud hashing is pointed to? Is it one of the public ones like GHash, or their own private pool? |
|
|
|
|
Show Posts
