What address were you using for standard p2pool mining out of curiosity? I'd be curious to take a look at the difference between the two.
Sure, you can check it out. The address is 1Km6zTdCfZATTTVGcMabJ7BrwcopYvRp5W. You can see it running on my backup node at 104.131.12.128:9332. Looks like you've got more than double the hash power pointed at that one.  That's probably helping your variance a bit for this test as well. I'm not entirely sure what you mean? Unless you're looking at expected payouts in the share explorer or on windpath's node... in which case, you'll see it's been a little lucky the past few days. I can assure you, however, that the wallet address I provided belongs to a single S3 that began its mining life for me on 8/19/2014. The miner has done pretty well for itself - earning 0.87270703 BTC from p2pool since it started. According to http://retrocalc.net, the expected earnings for that timeframe at 440GH/s is 0.783 BTC, so I've made 111.46% of expectations. |
|
|
|
What address were you using for standard p2pool mining out of curiosity? I'd be curious to take a look at the difference between the two.
Sure, you can check it out. The address is 1Km6zTdCfZATTTVGcMabJ7BrwcopYvRp5W. You can see it running on my backup node at 104.131.12.128:9332. |
|
|
|
A shame the latency is so much different on the 2 servers. I think that is highly effecting your results. Would've been great to see NastyPoP vs Standard payouts tested on the same node. I have a feeling that is the reason NastyPoP is lower in your results.
I appreciate you taking the time to do this. Very nice write-up. Did you pay any attention to the differences in statistics between the 2? Like how fast your miner showed up poolside or how accurately your hashrate was reported? Those are a couple major benefits to NastyPool as well.
I believe you're correct about the latency killing me, but there's not a whole lot I can do unless you decided to open up a server here on the east coast of the US. I was happy to do the writeup, and am glad to be able to help you out by providing the comparison. One thing I forgot to mention in the OP is that if your pool finds the block, that 0.5% finder's reward is given out to the miners as well - a very nice touch! I did pay attention to the stats as well. NastyPoP records a very accurate hash rate graph - showing my S3 consistently at 440GH/s. Your graphs are quite nice - showing not only the actual and mean hash rate, but also if a share was found. Nice job on those. Here's a screen showing my miner:  |
|
|
|
These pools you mention are giving you the illusion that you are getting overpaid - that's all it is, an illusion. No pool can pay more than they mine, the same as no business can run at a loss. Any pool that claims to pay more than they earn should be avoided completely, especially one that has a proven shady background. Don't fall for it.
My first payment from WestHash today for 5 hours of mining was almost double what I would have gotten from 24 Hours of PPS payouts. No illusion as the payment hit my wallet. People right now are paying a high amount for the hash rate to mine a new coin. Hope this last a while longer but will slow down soon I am sure. Yeah, people are paying out the wazoo to mine GAW's new XPY. Those of you who have rigs for rent are making a killing right now  . Supposedly the PoW mining stage will be completed on 12/19, so enjoy it while it lasts! |
|
|
|
|
As has been alluded to in the original post and in the discussion between OgNasty and myself throughout this thread, the results of the comparison between NastyPoP and p2pool are pretty anecdotal.
I think the primary focus here should instead be upon what OgNasty and Nonnakip have done to try and solve the problem of variance inherent in p2pool mining, especially for the smaller miner. For example, I'm using S3s for this test because, well, that's the equipment I own. As of now, the S3 is still a pretty viable mining device to use by itself on p2pool. The chances are pretty good that the S3 is going to have a share on the chain every time a block is found. This means that my equipment really isn't suffering too badly from the variance problem to begin with and hence the payout normalization provided by NastyPoP shouldn't have too much of an effect.
My point here is that over time, the payouts from p2pool and NastyPoP should naturally converge, all things being equal. There will be times when my S3 mining on the traditional node will not have any shares on the chain when blocks are found. This will become more evident as share difficulty increases and total pool hash rate increases. I will see blocks of no payouts, along with blocks of getting them. With NastyPoP, I'll always see a payout for work that has been contributed, assuming of course that the combined efforts of every miner on NastyPoP have indeed found shares.
That is the primary difference between NastyPoP and traditional p2pool mining, and needs to be stressed. Miners with lower hash rates won't have the impression that they've wasted their time and not gotten any reward for their mining. Rather than see 5 blocks with no payouts, then 5 blocks with payouts the miner will see 10 straight blocks of payouts.
I hope anyone who is reading this thread can find some useful information and make some informed decisions on how they want to proceed. I applaud OgNasty and Nonnakip for taking the time to devise and implement their solution.
|
|
|
|
TL;DR - Comparison of payouts of NastyPoP and NastyP2P. Here's the current chart showing payouts over time:  Expected Payouts vs Actuals  Raw spreadsheet: https://www.dropbox.com/s/vv7r7ejq2pquynl/pop_vs_p2p.xlsx?dl=0A couple weeks ago I wrote a post comparing p2pool's payouts to those of BAN, clearly showing that p2pool has paid out an average of 112.63% of expectations over the lifetime of the BAN pool. BAN pays 110% PPS, so p2pool has beaten it by 2.63%. You can see my post here: https://bitcointalk.org/index.php?topic=875644.0. After reading my thread, OgNasty asked if I would do a similar comparison between p2pool and his newly created NastyPoP pool. For those of you who do not know what that is, let me briefly describe it. OgNasty has been running his own p2pool node for a long time at nastyfans.org. During the existence of his pool, he's offered some pretty interesting additions to standard mining, including the ability to purchase "seats", which effectively give the owner of a seat a membership to the nasty fan club. The seats themselves are special 1 ounce silver coins that are actually pretty cool. You can check them out here: https://nastyfans.org/mint. As anyone who has been involved with p2pool is aware, one of the biggest problems with the pool is variance. Specifically, as the pool grows, individual miners suffer greater and greater variance. This is precisely the opposite of what happens in a more traditional pool like BTCGuild, where the larger the pool gets, the steadier the payouts become. OgNasty and Nonnakip decided to do something about it and introduced NastyPoP. Effectively, this is the first real attempt by anyone to try and tackle the p2pool variance problem. Bitmain's p2p AntPool is also out there, but it seems to be stuck in limbo, so who knows. So how does it work? Well, with a regular p2pool node you connect your miner by providing a bitcoin wallet address as the username and anything as a password. If and when your miner finds a share with a difficulty greater than the target share chain difficulty, your share gets added to the chain. When the pool finds a block, you get paid for the shares you have in the current payout list of the chain. NastyPoP is a bit different. When you connect, you still provide your bitcoin wallet address, but you append -PoP to the end of it. This signifies to the nasty pool that you are going to use their proprietary payout system. Underneath the scenes, OgNasty and Nonnakip have created a sort of "pool on top of a pool". Everybody who is connected using the -PoP suffix is in reality mining to the node's payout address. You can try this on your own node. Simply provide something that isn't a valid wallet address as the user name, and if you find a share, it is the node's default payout address that gets the credit for the share. Well, here's where the custom code comes into play. OgNasty and Nonnakip have devised a way to put a PPLNS payout system very similar to a traditional pool in place on top of p2pool's backbone. They are tracking shares for your miner just like a traditional pool would. Every miner who has the -PoP suffix shares in the block reward when p2pool finds a block, based upon how many valid shares that miner has contributed during the payout shifts. I don't have the exact details on how long shifts are, or what the share clip length is, and as I wrote, the code is proprietary and not yet open-sourced. Payouts from NastyPoP are on Fridays at 19:00 UTC. They are sent just like any other transfer and require only 6 confirmations. P2Pool payouts happen as soon as the block is found and require 101 confirmations. How does this reduce your variance? Simply put, your miner is paid out in small increments based upon your contributions, rather than being dependent on finding a share to add to the share chain. That job is left to the node's payout address. All in all it's quite a clever implementation of reducing p2pool's variance for smaller miners. One thing that's very important to note here about NastyPoP: you can't take your work with you if you move to a traditional p2pool node. No other node out there has any clue whatsoever of the work you've been doing on NastyPoP. In this fashion, NastyPoP behaves much more like a centralized pool the likes of BTCGuild than a p2pool node. I think it's great that OgNasty and Nonnakip have taken the initiative and are trying to help solve the variance problem. Unfortunately, the solution they've come up with defeats the very nature of the decentralized p2pool. Yes, it helps eliminate variance, but at the cost of forcing you to remain tied to the NastyPoP node. That's all fine and dandy, but how does it compare? To test this out, I pointed an Antminer S3 at the NastyPoP node, and another S3 at my own standard p2pool node. Each S3 is configured to run at stock speeds (440GH/s), and I set a static pseudo share difficulty of 500 on both. Both are powered by an EVGA 1300 G2 and hardwired into an always-on gigabit home network with more than enough up and down bandwidth. Let's take a look at the ping times from my miner to the pool: --- nastyfans.org ping statistics --- 57 packets transmitted, 57 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 115.153/144.510/277.534/45.255 ms An average of 144.51 would stop me from pointing a miner there if it were a standard p2pool node. Let's see where the server is. Running a traceroute shows the last hop in Germany. Well, that explains the ping time - I had to go to Europe . Our friends on that side of the pond would probably be better served. Another thing I noticed was a much higher reject rate from the NastyPoP pool than I do on my own nodes. This could be due to the latency, but it turned into about 12-14% rejects, whereas I typically see less than 1% on my own nodes. Alright, so how did the payouts work? Here are the results: 11/28 - 12/5 NastyPoP - 0.03379787BTCP2Pool - 0.03589959BTCExpected - 0.0385BTC12/5 - 12/12 NastyPoP - 0.03238691BTCP2Pool - 0.03937531BTCExpected - 0.0387BTC12/12 - 12/19 NastyPoP - 0.03382075BTCp2pool - 0.07363736BTCExpected - 0.0389BTC12/19 - 12/26 My p2pool node - 0.05615571BTCNastyPoP - 0.05015601BTCExpected - 0.0393BTC12/26 - 1/2 My p2pool node - 0.03205607BTCNastyP2P - 0.03861873BTCNastyPoP - 0.02812263BTCExpected - 0.0388BTC1/2 - 1/9 My p2pool node - 0.024337627BTCNastyP2P - 0.06870469BTCNastyPoP - 0.04531921BTCExpected - 0.0381BTC1/9 - 1/16 My p2pool node - 0.00419189BTCNastyP2P - 0.01805329BTCNastyPoP - 0.02152612BTCExpected - 0.0367BTCP2Pool 7 day luck - 62.25% 1/16 - 1/23 My p2pool node - test discontinued due to hardware failure NastyP2P - 0.03989456BTCNastyPoP - 0.02833329BTCExpected - 0.0352BTC1/23 - 1/30 NastyPoP - 0.01963295BTCNastyP2P - 0.02061486BTCExpected - 0.0361BTCLuck - 81.85% 1/30 - 2/6 NastyPoP - 0.05905592BTCNastyP2P - 0.02003162BTCExpected - 0.0375BTCLuck - 93.32% 2/6 - 2/13 NastyPoP - 0.00435959BTCNastyP2P - 0.00938869BTCExpected - 0.0361BTCLuck - 14.3% 2/13 - 2/20 NastyPoP - 0.00698833BTCNastyP2P - 0.01822003BTCExpected - 0.0348BTCLuck - awful 2/20 - 2/27 NastyPoP - 0.03798674BTCNastyP2P - 0.04202049BTCExpected - 0.0338BTCLuck - 100.64% 2/27 - 3/6 NastyPoP - 0.02048889BTCNastyP2P - 0.00942830BTCExpected - 0.0332BTCLuck - 51.98% 3/6 - 3/13 NastyPoP - 0.05138458BTCNastyP2P - 0.05908961BTCExpected - 0.0328BTCLuck - 131.5% 3/13 - 3/20 NastyPoP - 0.03402797BTCNastyP2P - 0.05156673BTCExpected - 0.0327BTCLuck - 101.66% 3/20 - 3/27 NastyPoP - 0.02843568BTCNastyP2P - 0.01970915BTCExpected - 0.033BTCLuck - 90.54% 3/27 - 4/3 NastyPoP - 0.03301631BTCNastyP2P - 0.05550941BTCExpected - 0.0332BTCLuck - 97.55% 4/3 - 4/10 NastyPoP - 0.02866930BTCNastyP2P - 0.03528256BTCExpected - 0.0318BTCLuck - 113.4% 4/10 - 4/17 NastyPoP - 0.00028594BTCNastyP2P - 0BTCExpected - 0.0313BTCLuck - 0% 4/17 - 4/24 NastyPoP - 0.05554895BTCNastyP2P - 0.05281205BTCExpected - 0.0321BTCLuck - 165.47% 4/24 - 5/1 NastyPoP - 0.02111442BTCNastyP2P - 0.02415729BTCExpected - 0.0325BTCLuck - 59.99% 5/1 - 5/8 NastyPoP - 0.03294026BTCNastyP2P - 0.05447989BTCExpected - 0.0325BTCLuck - 127.84% 5/8 - 5/15 NastyPoP - 0.03472755BTCNastyP2P - 0.02216391BTCExpected - 0.0325BTCLuck - 84.97% 5/15 - 5/22 NastyPoP - 0.05258228BTCNastyP2P - 0.03171723BTCExpected - 0.032BTCLuck - 182.64% 5/22 - 5/29 NastyPoP - 0.04249927BTCNastyP2P - 0.03263267BTCExpected - 0.0307BTC5/29 - 6/5 NastyPoP - 0.03711295BTCNastyP2P - 0.03414086BTCExpected - 0.0312BTC6/5 - 6/12 NastyPoP - 0.04351160BTCNastyP2P - 0.04518917BTCExpected - 0.03144BTCLuck - 122.76% 6/12 - 6/19 NastyPoP - 0.01964088BTCNastyP2P - 0.02788807BTCExpected - 0.030107BTCLuck - 65.12% 6/19 - 6/26 NastyPoP - 0.02159208BTCNastyP2P - 0.0193531BTCExpected - 0.030107BTCLuck - 60.76% 6/26 - 7/3 NastyPoP - 0.02828584BTCNastyP2P - 0.01623161BTCExpected - 0.030263BTCLuck - 81.3% 7/3 - 7/10 NastyPoP - 0.02039533BTCNastyP2P - 0.02521461BTCExpected - 0.030289BTCLuck - 71.40% 7/10 - 7/17 NastyPoP - 0.02054230BTCNastyP2P - 0.02884854BTCExpected - 0.03493028BTCLuck - 71.40% 7/17 - 7/24 NastyPoP - 0.04771791BTCNastyP2P - 0.04040042BTCExpected - 0.03465856BTCLuck - 162.79% 7/24 - 7/31 NastyPoP: 0.04298881BTCNastyP2P: 0.03145364BTCExpected: 0.03401418BTCLuck - 134.83% 7/31 - 8/7 NastyPoP: 0.01487946BTCNastyP2P: 0.01145337BTCExpected: 0.02962897BTCLuck - 55.38% 8/7 - 8/14 NastyPoP: 0.03914884BTCNastyP2P: 0.07990332BTCExpected: 0.02941349BTCLuck - 241.06% 8/14 - 8/21 NastyPoP: 0.03640067BTCNastyP2P: 0.04331323BTCExpected: 0.02939197BTCLuck - 138.27% 8/21 - 8/28 NastyPoP: 0.01170063BTCNastyP2P: 0.02753223BTCExpected: 0.02857788BTCLuck - 54.07% 8/28 - 9/4 NastyPoP: 0.0455039BTCNastyP2P: 0.04888988BTCExpected: 0.02846873BTCLuck - 180.68% 9/4 - 9/11 NastyPoP: 0.01466154BTCNastyP2P: 0.00815205BTCExpected: 0.02719480BTCLuck - 63.24% Running totalsNastyPoP: 1.54926483BTCNastyPoP from 12/26: 1.39910329BTCNastyP2P: 1.48230244BTC (test started 12/26) Expected earnings: 1.69383675BTCExpected earnings from 12/26: 1.53839914BTCMy P2Pool Node: 0.265653547BTC - discontinued 1/16NastyPoP vs Expected Earnings from 11/28: 91.46%
NastyPoP vs Expected Earnings from 12/26: 90.95%
NastyP2P vs Expected Earnings from 12/26: 96.35%My P2Pool Node vs Expected Earnings from 11/28 - 1/16: 98.76% - discontinued |
|
|
|
|
I've mined in p2pool since the end of March, with forays into other pools every now and then to see what they were about. Always ended up back here. I like running my own node and the concept of p2pool.
|
|
|
|
In the last post are you saying that each miner should be a S3+ or higher per miner or a total of each user hash rates of all miners assigned the one payout address. I have 7 s3+ mining on my node and there all using the same Pay out address. this seems to work ok, or would it be better to assign each miner there own payout address.
I also have 5 S2 that are pointing to a other pool. that seem to average 8-9 blocks a day so they make about double what my 7 S3+ do on p2pool node.
I was saying that minimal entry would be about an S3+ worth of hashing power. You're doing the same thing I do - all my S3 use the same address to mine, so my node thinks I've got about 4TH/s (well, less now because I'm doing some testing). As for earnings, there are a number of threads showing how p2pool has done compared to other pools. Over the long run (since January of this year when then experiment began for BTCGuild and Eligius, and since July when BAN opened its door), p2pool has out-earned Eligius, BTCGuild and BAN. You're doing just fine if you've found 8 shares in 24 hours. A quick and easy way to check and see what the p2pool network thinks your hashing power is, go to http://minefast.coincadence.com/p2pool-stats.php and click on the Active Miners tab. Find your address in that list. If it shows higher than your actual hash rate, you've found more shares than average. If it's lower, you've found fewer shares than you should have. |
|
|
|
I can definitely understand the points both you and kano made and agree with you that the addition of empty blocks to the chain is a necessary evil in the current state of things.
The issue wasn't whether it's okay to generate empty blocks or not. The issue is a pool creating empty blocks when there are transactions pending due to a pool's poor optimisation choices. P2pool by itself does not do anything to limit transactions as an optimisation, it just uses whatever it is given by the bitcoin daemon. That points the finger at the custom antpool implementation as being responsible. Yes, it does. Just like the other example kano pointed out. My initial statement was that I felt the addition of empty blocks to the blockchain just for the sake of adding a block seemed to be contrary to what the blockchain itself is: a record of transactions. Both kano and syke provided very good reasons why they are allowed. I accept their points as valid, which is why I stated the addition of the empty blocks is a necessary evil. I also fully agree that some pool implementations are just plain bad coding decisions. Again, as both you and kano point out, there are a number of pool options that do not make such choices (your pool and p2pool being two such examples). And, just to stay on topic, AntPool is an example of poor implementation since it is producing those empty blocks in the first place. |
|
|
|
Okay, this is probably an idiot question, but here it goes. I really support the whole concept behind P2p, so I tried to mine in this pool. I had low ping with coincadence.com, so I pointed my miner their... now, all I did was point my miner their via cgminer.... if I'm pointing to a node, do I need to run an instance of p2p and bitcoind local? On the stats page I was getting a hashrate, but on my cgminer output I was getting "share accepted" once every blue moon, and instead I was getting a lot of "stop work requests". I found a small non-p2p pool with low ping and pointed their, and saw cgminer start spitting out accepted shares constantly. NOw, I assume this is because the p2p pool has a a bajillion users, whereas the non-p2p pool I found has ~200, so my miner was really only getting a smaller amount of work on the p2p pool (  ) But the more I look into p2p, I'm thinking I may have done something wrong. Not stupid questions at all... If you point your miners to a remote node (like windpath's), you do not need to locally run an instance of p2pool or even bitcoind. All you need is a valid bitcoin wallet address to which your portion of the block reward can be paid when a block is found. The reason you see "share accepted" only once in a blue moon on a p2pool node vs all the time on a regular node has to do with the share difficulty. If you connect to a p2pool node using only your bitcoin wallet address, you will be assigned a share difficulty by the pool. The pool determines share difficulty based upon its total hashing power. You can override this if you want by using +XXXX at the end of your wallet address. For example, if you put 1DevLdogN52pHdjZnsgi4HzreFDB4ZHVre+500 as your username, you're telling the node that you wish it to consider all shares from your miner of difficulty 500 or more. The lower that number, the more "share accepted" messages you'll see. Remember, however, that those low difficultly shares mean absolutely squat. Their only purpose is to give you visual reassurance that your miners are actually submitting work to the node. A typical traditional pool will assign you a variable difficulty. For example, if you were to mine on ckolivas' solo pool, that pool dynamically adjusts the share difficulty based upon your hash rate. Again, and especially on his solo pool, those low difficulty shares mean nothing. There are other payout methodologies and share difficulty settings in use, so it can get confusing. Back to p2pool, the only share you submit that matters is one that at least matches the target difficulty of the share chain. If it does, then your share is added to the chain and if that share happens to be in the payout list when the pool finds a block, you get your coin. Right now, that difficulty is just about 10 million. P2Pool constantly adjusts the share difficulty to try and maintain an average of 30 seconds per share added to the chain (just like Bitcoin adjusts its difficulty every 2016 blocks to try and keep the average block time of 10 minutes). People have different views on how much hash rate you should have to be mining on p2pool. A good rule of thumb I use is "do I have a high enough hash rate to expect to find 1 share in the average amount of time it would take p2pool to solve 3 blocks". If yes, then you would expect to have at least 1 share on the chain for every block p2pool finds. If we use this rule, we can figure out how much hashing power constitutes the entry point: Difficulty * 2^32 / hash rate = expected time to find a share
10436491.83 * 2^32 / hash rate = 179100
hash rate = ~250GH/s
Keep in mind that the difficulty is constantly changing and the p2pool total hash rate is constantly changing. For example, while I was typing this reply, the expected time to block for p2pool went from over 16 hours to under 15. This has an effect on the above calculations, which in turn changes the baseline for how much hashing power you should have. So, how much hashing power should you really have on p2pool? An S3+ typically does it... an S2 is better... an SP20 even better still. If you've got anything under an S3 (like an old S1), then expect to see a ton of variance where you'll go for a number of blocks with no payout at all because you haven't found any shares. This is one of the primary issues p2pool has - the more hashing power the pool has, the greater the variance experienced by individual miners. As you can see from the first post on this page, people have been trying to find a solution for a long time. Sorry about the long-winded post. I tried to give you as much information as possible to help you better make a decision on whether p2pool is the right choice for you. |
|
|
|
Honestly I don't even understand why a no transaction block should be allowed in the first place. It has no purpose on the block chain since it isn't recording any transactions.
Prohibiting empty blocks is worse than pointless. If empty blocks were prohibited, fake transactions would be created and permanently bloat the blockchain to get around the limitation. Each block, empty or not, increases the security of every previous transaction. Sounds like a good thing to me, don't you think? I hear you, and certainly recognize how the addition of blocks onto the chain increases the security of the previous transactions. All I meant by my statement was that from the standpoint of the blockchain it didn't make sense to record a blank because at its core, the blockchain is a record of transactions. I also recognize that since there needs to be a way to bring coins into circulation, we need to have blocks constantly added to the chain to generate the coins. If we truly want to keep the blockchain bloat free, prohibiting blocks empty of transactions as well as those containing "fake" transactions would prove useful. However, I have no idea how you'd determine whether or not a transaction was "fake", or if such a thing is even a possibility. Kano made a great point describing how pools are guilty of making bad decisions such as handing out empty blocks, for which a miner certainly could generate a successful solution. Anyway, I think we've completely gone off topic here in this thread and should probably move it somewhere more appropriate if we're going to continue. I can definitely understand the points both you and kano made and agree with you that the addition of empty blocks to the chain is a necessary evil in the current state of things. |
|
|
|
https://en.bitcoin.it/wiki/DifficultyThe expected number of hashes we need to calculate to find a block with difficulty D is therefore
D * 2**256 / (0xffff * 2**208) Yeah, the meaning is the same. Thanks for the clarification! |
|
|
|
It's not precisely the same.
2^32 = 2^48/2^16 = 4294967296
2^48/(2^16-1) = 4295032833
Compare the two when using 1 Th/s:
1*10^12 * 25 * 86400 / (2^32 * 40007470271) = 0.01257051 BTC/day
1*10^12 * 25 * 86400 * 65535 / (2^48 * 40007470271) = 0.01257032 BTC/day
You can see the values starting to diverge.
I know it's not precisely the same... hence why I pointed out it was 65535/65536 So... what do those two things represent in your formula? 65535 and 2^48? I've never seen any version of that formula before in reference to calculating expected earnings per day, so I'm curious to their meanings. For example, is the formula I posted the "lazy man's" version of yours? In other words, did somebody take a shortcut and just say, "well, for all intents and purposes, just use 2^32 instead of 2^48/2^16-1 since it doesn't have that much effect"? In my formula, I use 2^32 to represent a difficulty 1 share. Is that the same meaning in yours of the 2^48/2^16-1? Thanks! |
|
|
|
I like this one, it's clean & tidy - I use it on my DRK node  Just got back online after nearly two days of no electricity - high winds knocked everything out here......sorry to anyone who was mining on my nodes. Welcome back... glad to see you survived the weather bomb / end-of-days |
|
|
|
The simplest equation is:
Reward = Hash Rate * Block Reward * Time Period * 65535 / (2^48 * Difficulty)
The hash rate is measured in hashes per second and the time period is measured in seconds. For example, at a difficulty of 40007470271, 1 Gh/s would mine:
1*10^9 * 25 * 86400 * 65535 / (2^48 * 40007470271) = 0.00001257 BTC/Day
I'm not entirely sure how that formula is the simplest one... especially with the introduction of the random 65535 constant that is offset by dividing by 2^16. The more commonly accepted formula to calculate expected earnings per day is the one I provided, which you can get from yours by removing that unnecessary constant (65535/65536), which I don't know why you included in the first place since it makes no sense: Reward = hash rate * block reward * time period / (2^32 * difficulty)
Precisely the same as: block reward / (difficulty * 2^32 / hash rate / time period)
Using your 1GH/s miner: 25 / (40007470271 * 2^32 / 10^9 / 86400) = 0.00001257
|
|
|
|
guide for windows ? any ? the bitcoind is taking ages to sync up, my windows bitcoind is sync'ed.
ok got windows version running, now how to mod the interface ? i found some nice ones on git but don't really know how to add/implement it. i tried to use this https://github.com/justino/p2pool-ui-punchy but no success You just drop it into your web-static folder if you want to replace the default one. |
|
|
|
They are easy to find here - https://www.antpool.com/poolStats.htm - just by looking for the ones that are only 25 BTC and no change. a bunch of orphan ones as well. so how do you mine a block with no transactions. It is not hard to do, you simply do not include them. It is just plain bad for bitcoin, all around. The worst part is any benefit of including 0 transactions is miniscule, by not including transactions your found block is smaller which results in hundredths of a second faster block propagation time and perhaps a 0.0001% better chance your block does not get orphaned. It's selfish and slows down transaction processing for everyone. As bad as the centralization the discus fish and ghash create is, at least they mine big fat blocks with many transactions... +1 If Bitcoin survives as it is currently designed, the day will come when transaction fees HAVE to be the large part of the block reward, as the block reward will continue to diminish in size. For those that haven't been around, blocks started out at 50BTC. Now they are at 25BTC, and the time isn't too far off when it'll halve again to 12.5BTC. Any pool that purposes puts out blocks without transaction fees is hurting Bitcoin. The same goes for any pool that grants all transaction fees to the block winner. That can't continue. M A ton of pools are going to be put out of business when transaction fees become the main source of revenue for mining blocks. Many others are going to have to rewrite their code to distribute those fees out to miners in addition to the block rewards. Honestly I don't even understand why a no transaction block should be allowed in the first place. It has no purpose on the block chain since it isn't recording any transactions. |
|
|
|
I was looking for a P2Pool node to mine in and I saw that the version ended with -dirty. Can anyone explain to me what that means? Is it caused by altered code? It seemed most of the nodes with dirty had customer landing pages. I searched for the answer, but couldn't find any detailed answers.
I answered you in the other thread you posted in the Mining forum. Here's the copy/paste: I must have missed your question in the p2pool thread. It has to do with a git command. The version info is pulled from you local git repo of p2pool. Basically, in __init__.py, it makes a call like this: git describe --always --dirty
As you rightfully suspect, if you've added files to your local repository (for example, a custom front end), then git will return back that your repository is "dirty". |
|
|
|
I must have missed your question in the p2pool thread. It has to do with a git command. The version info is pulled from you local git repo of p2pool. Basically, in __init__.py, it makes a call like this: git describe --always --dirty
As you rightfully suspect, if you've added files to your local repository (for example, a custom front end), then git will return back that your repository is "dirty". |
|
|
|
The formula is very simple: BTC earned per day = Block Reward / (Difficulty * 2**32 / hash rate / seconds in a day)
Does time between blocks matter at all in this calculation? It seem that it would, but maybe I am missing something. If BTC is 25 coins per block, once every 10 minutes (on average), how would it change if say if blocks of 25 were found say ever 1 minute? It wouldn't. The formula is "expected earnings per day based on a given difficulty and hash rate". It doesn't care about how many blocks are solved in a day. It only cares about what your expected daily earnings are. If you were to break down the formula, the denominator is effectively solving how many days you would expect it to take to find a block. The numerator is the block reward. Broken down we show first "how many days should I expect to find a block given a difficulty of X and a hash rate of Y"? I'll use 1TH/s and current difficulty of 40007470271: 40007470271 * 2^32 / 1000000000000 / 86400 = 1988.78 days
Given that answer we know that with 1TH/s at the current difficulty, we would expect to find a block of 25 BTC after 1988.78 days (I rounded to two decimal places). So, if we want to find out how much we can expect to earn a day we just take the block reward and divide it by the number of days to find that block: 25 / 1988.78 = 0.01257052
So, you can expect to earn 0.01257052 BTC a day right now with a 1TH/s miner. Keep in mind, this formula is only there to provide a base of what the expected earnings are given an ideal set of circumstances. Obviously in the real world, you can earn more or less since the process of mining itself is based upon luck so time to solve varies, the payout mechanism of the pool on which you're mining varies, fees and donations vary, transaction fees on a block vary, etc. |
|
|
|
|
Show Posts
