|
Another week down, and this week we see for the first time NastyPoP's variance reduction payouts winning out over standard p2pool for one of my miners. The miner on my node had just plain awful luck at the beginning of the week. It had no shares on the chain and missed payments for 5 of the blocks p2pool found. My miner on the NastyPoP node was paid for every found block. I'm very happy we've now seen this, and the payout results reflect the fact that my miner missed those 5 blocks. So... here are the results for my miners for the week:
My standard p2pool node - 0.024337627BTC
OgNasty's standard p2pool node - 0.06870469BTC
NastyPoP p2pool - 0.04531921BTC
Expected - 0.0381BTC
P2Pool 7 day luck - 152.23%
Look very closely at the difference in the payouts between my two miners on standard p2pool payouts. They are both S3s. They are both clocked at 218.75 to get 440GH/s. They're both running on the same EVGA 1300 G2. Yet, the S3 on my node only made 0.024337627, while my S3 on nastyfans.org made 0.06870469. That's the variance that p2pool miners see, and what the NastyPoP system normalizes.
P2Pool, in general this week beat expected earnings. My miners on nastyfans (both the regular and the NastyPoP) followed that trend and beat out expected earnings.
OP has been updated with this week's results.
|
|
|
|
Well, We plan to setup a Pi to give him remote control of the box. So I won't do any managing short of a hard power reset if needed.
If he decides not to pay, I have his miner...
I plan to charge a flat fee for power consumption costs. That's a min at a cash value.
I was thinking of having him set his mining payout to coinsplit.io
And just take a percentage, I was thinking 10-15%???
Setting up a Pi for remote access is nice. Takes a lot of the hassle off of you for everyday changes the owner might wish to make. In terms of charging the flat fee, how are you planning to bill the guy for it? Just send him an invoice for $20 every month for the electricity costs? Put it this way - that S5 right now expects to earn 0.01429 BTC a day, which at current BTC prices is $4 a day thereabouts. At 30 days a month, your $20 is already about 16.67% of his mining profits. Adding another 10% to it would mean you're asking him for 26.67% of his mining profits. Again, this is right now. That changes each difficulty change and also changes as BTC prices fluctuate. That's the problem with charging fees in fiat - it results in different percentages of mined BTC being paid to you. You can certainly simplify things and tell the guy, "look, as of right now, I will charge you a flat 25% of what you mine. This rate will be reviewed weekly and changed as appropriate based upon current value of BTC in fiat and/or how much the miner currently makes based on network difficulty." |
|
|
|
I have someone asking me to host their miner for them. Thus far only a single Antminer S5 I've calculated power consumption to be $20 ish a month. But it's taking up space, using my net etc. So what do I charge them? A percentage of the machines profit? A flat fee? I don't want to over quote and insult, or under quote and screw myself out of profit  It really depends upon what you're trying to achieve here. The miner will take up space, generate heat, use electricity, make noise, use your bandwidth, etc. This is in addition to you having to babysit the miner - configuring it, making changes at the owner's request if he wants to mine a different pool, and so on. So... what's that worth to you? Are you looking to make some money from this deal? If yes, how are you anticipating being paid for your hosting services? What do you do if/when the owner decides not to pay? Lots of things to consider |
|
|
|
The main advice I'd give is that picking PPS for the payment method is a bit risky. This means you'll be paying miners out of pocket until you find a block. You are taking the risk of variance. There's a paper around somewhere that shows a formula for computing what sort of buffer you need, in bitcoins, to run a PPS pool with a low risk of ruin (ie. running out of money to pay miners). It's large - you'll be need a few hundred thousand dollars of bitcoins if I recall correctly.
The other downside of PPS is you are open to block withholding attacks. A miner mines with you but withholds all solutions that would solve a bitcoin block. You are still paying them PPS so they lose nothing. The pool loses a lot.
Interesting... Seems like PPS isn't ideal for a new pool starting out. Would it be better to start with something else until blocks are found, then switch to PPS? PPS itself isn't ideal for a pool operator as the pool takes on all the risk. Like mmpool states, the miner gets paid no matter what and it's up to you to figure out how to ensure the payments happen, regardless of whether or not your pool has found a block. Here's a simple example of what I mean: Pool finds a block of BTC, yay! Unfortunately, it took twice as many shares as expected to do so. You have to pay your miners 50 BTC but you've only got 25 BTC from the block reward. Orphaned blocks are bad, too. You as the pool operator expect to have that 25 BTC to pay your miners, but you don't because the block the pool submitted was orphaned. There's a reason that the vast majority of the pools that do offer PPS do so at an extremely high fee percentage (4% or more). There is currently only 1 PPS-based pool that I know which charges 0% fees, and that's BitAffNet. You can find quite a few threads on these forums about them - I'd suggest looking them over. |
|
|
|
Do they antpool p2pool nodes get payments from p2pool blocks??
Hope they close down their nodes soon enough.
No, as IYF mentioned, they don't use the standard p2pool share chain. So do I. Sooner the better. The way I see it, and please correct me someone if I'm wrong, but they are simply piggy backing off p2pool decentralization marketing, and by using the same ports as p2pool they are stealing/fooling miners into thinking that they are actually helping p2pool decentralization/network - when the opposite is in fact the case. As things are, they are harming the p2pool network. What can be done? Well, short of every p2pool node banning the IP of antp2pool & pestering them to change their ports - not a lot  Again, someone please correct me if I'm wrong. You're not wrong. I spent some time going through their p2pool code when they released it. All they did was add some reliance upon a database to capture/store worker/share info. It wasn't complete and I don't know that they ever pursued it any further. They certainly jumped on the decentralized bandwagon, but have done nothing except for talk about how they support it, while behind the scenes they aren't doing squat. The last update to the code was on November, 13, 2014. |
|
|
|
Not sure I'd say perfectly? The still default to 8192 queue size and large amounts of stales. I got mine down to about 3.4% stales, which is almost twice as bad as my SP20s at 1.8% stale. Thanks for the ck firmware link, didn't know about that, will have to try it. M Definitely give the firmware a try, you'll get better results. You'll want to follow this to set queue to 0: https://bitcointalk.org/index.php?topic=796839.msg9243760#msg9243760I also add --scan-time 1 --expiry 1 along with lowering queue to 0 and adding --lowmem. Quite a pain in the ass to do every time the machine goes down, but worth it IMO. CK has stated a few times that the --scan-time and --expiry parameters are useless, so you really don't need to bother with them. I hadn't tried --lowmem before, so I can't tell what value it adds if any. The biggest bang for the buck is setting --queue to 0, instead of their default 8192. |
|
|
|
Thanks for the info, guys. To open it up to the public make sure ports 9332 and 9333 are open to the public and map to your p2pool server on your LAN... Should 8333 be opened also to provide better node connectivity? I currently have 8333 and 9333 open. Any security precautions to take into consideration? Edit: Opened up 9332, and allowed responding to pings. http://69.157.250.149:9332/static/Would you fellas mind pinging my server and posting your results? Specifying your general location would be appreciated, too. The server is located in Montreal, Canada. I just checked out your node... 5 S4s on it, 4 of which are reporting 2TH/s or greater. Looks like whatever firmware you're running is working out well on p2pool. Guess Bitmain finally got around to fixing that, huh? I'm traveling for work this week (currently in Cleveland, OH). Ping to your server from here: round-trip min/avg/max/stddev = 48.655/56.074/85.242/7.561 ms Have you checked out Matt's relay network? https://bitcointalk.org/index.php?topic=766190.0 |
|
|
|
|
Check out the threads on "pencil mod" for the S1. I'm not sure how low you're going to get since those things came in at 2W / GH/s. There's far more efficient gear out there now, with even better efficiency gear on the horizon. Currently, the S5 from Bitmain and the SP20 from Spondoolies are about the best you're going to get.
|
|
|
|
If you're not afraid of a little math, you can figure out your expected payout pretty easily. A true PPS-based pool assigns a value in BTC to every share, which is derived from the current network difficulty and the block reward. As of right now, the difficulty is 40640955016, and the reward is 25 BTC. So, we can derive that each share is worth 25/40640955016, which is 0.00000000061514 BTC per share. That's all well and good, but how do you figure out how many shares your rig expects to submit in a day? Another formula will get you that value: Difficulty * 2^32 / hash rate / 86400 = expected time to solve a block in days. For a 1 TH/s miner, that value is 2020.27 days. Number of shares, divided by number of days = expected shares per day. That same 1TH/s miner expects to find 20116567.61 difficulty 1 shares a day. Take that and multiply it by the value of a share and you get expected earnings on a PPS pool per day. The 1TH/s miner expects to get 0.01237451 BTC a day. Since our friends at Discus Fish charge 4% for PPS mining, you would get 96% of expectations, which is 0.011879523 BTC. You can change those numbers to fit whatever hashing power you have to determine what your expectations would be. Hope this helps. Edit: Here's the formula all nice and prettied up for you to calculate expected earnings on discus fish. 0.96 * (25 / (40640955016 * 2^32 / hash rate / 86400))
Of course, if you're feeling really lazy, go to an online calculator like https://bitcoinwisdom.com/bitcoin/difficulty, plug in your hash rate, take the resulting expected daily earnings and multiply it by 0.96. |
|
|
|
I have a general gist of how pools work, but yes it would be ideal to get people in there to mine. I always learn by doing, so that's the purpose of this project. But on the other hand, I'm here asking for advice from seasoned veterans to avoid getting into any kind of trouble.
In that case, let me give you some advice . You're in for an uphill battle. Starting a new BTC mining pool is going to be tough. New pools are met with extreme prejudice because of the number of scammers who have taken advantage of the community. I wish you luck. |
|
|
|
|
I'm pretty sure if kano were to make a hypothetical recommendation, he'd tell you to go with the CK pool.
I've gotta ask what you're doing. You're looking for recommendations on how to setup/run a pool to what end? If you're expecting people to come and mine on a pool that you're launching you might want to have a bit more knowledge to start. Not knowing what you're doing when setting up and configuring a pool is just asking for trouble. Ask yourself if you'd go and deposit money into a bank where nobody in the bank knew how it worked and just setup something at random.
|
|
|
|
I was trying to set the pseudo share size high to reduce my bandwidth usage. I'm still constricted by my DSL bandwidth.  Thanks for proving what I saw. M Your miners and your node aren't on the same network I presume? Can you run your p2pool node on the same local network as your miners? The vast majority of the bandwidth being consumed by p2pool is the broadcasting of the share chain data, not the data from your miners. I don't know how you've got things setup (like co-located miners, but running the p2pool node from your home PC, or miners in your home, but running the p2pool node on a VPS). Bandwidth limitations suck. Sorry you're suffering from it EDIT: one thing you can do, if you haven't, is to ensure you aren't accepting traffic on 9333. Yeah, it'll turn off incoming connections to your node, but it'll definitely reduce your overall usage. You can also limit your connections to bitcoind and/or not allow traffic on port 8333. Nothing is coming in, and outgoing connections are limited. I have a VPS node, but it's on the other side of the country. I get 16% stale if I use it compared to 1.5% local. M If your miners and node are local, then that traffic is not going outbound, so it wouldn't impact your bandwidth limitations. I figured you'd already done the connection limit and shut down the inbound ports, but thought I'd mention it in case anyone else happened to have bandwidth limitations and hadn't done so yet. |
|
|
|
I was trying to set the pseudo share size high to reduce my bandwidth usage. I'm still constricted by my DSL bandwidth. Thanks for proving what I saw. M Your miners and your node aren't on the same network I presume? Can you run your p2pool node on the same local network as your miners? The vast majority of the bandwidth being consumed by p2pool is the broadcasting of the share chain data, not the data from your miners. I don't know how you've got things setup (like co-located miners, but running the p2pool node from your home PC, or miners in your home, but running the p2pool node on a VPS). Bandwidth limitations suck. Sorry you're suffering from it EDIT: one thing you can do, if you haven't, is to ensure you aren't accepting traffic on 9333. Yeah, it'll turn off incoming connections to your node, but it'll definitely reduce your overall usage. You can also limit your connections to bitcoind and/or not allow traffic on port 8333. |
|
|
|
The arguments are share difficulty and pseudo share difficulty: <bitcoin_address>/<share>+<pseudo_share> Setting <share> to 0 defaults to lowest p2pool diff, setting <share> to any number less then current p2pool diff will result the minimum current diff All setting pseudo share does is smooth out your graphs a little, it does not improve mining. <pseudo_share> is recommended to be calculated as your hash rate in KH/s times 0.00000116 i.e. for an S3 that actually runs at 440GH/s: 440,000,000 * 0.00000116 = 510.4 M, to answer your question directly, here is the code from work.py, starting at line 299: So you should be able to set it as high as you want... I never understood the point of the /parm. Just the +parm. I tried setting my miners to +7000000 and they all come up as 999,999. I got the same result with +5000000. M I wonder if the limitation is in CGMiner? on the p2pool node I see work size of 999,999. M It's limited in p2pool. You guys are looking in the wrong spot. From bitcoin/networks.py: SANE_TARGET_RANGE = (2**256//2**32//1000000 - 1, 2**256//2**32 - 1)
Here's the implementation of its usage in work.py: if desired_pseudoshare_target is None:
target = 2**256-1
local_hash_rate = self._estimate_local_hash_rate()
if local_hash_rate is not None:
target = min(target,
bitcoin_data.average_attempts_to_target(local_hash_rate * 1)) # limit to 1 share response every second by modulating pseudoshare difficulty
else:
target = desired_pseudoshare_target
target = max(target, share_info['bits'].target)
for aux_work, index, hashes in mm_later:
target = max(target, aux_work['target'])
target = math.clip(target, self.node.net.PARENT.SANE_TARGET_RANGE)
The difference between '+' and '/' is that '+' sets the pseudo-share difficulty (i.e. shares that p2pool cares about recording from this particular BTC address) and '/' can have an effect on your payouts if you set it higher than p2pool's minimum share difficulty. Set '+' too low and you'll see really pretty graphs with far fewer spikes because the node starts to care about more and more meaningless shares. You're also likely to see a whole lot more of those "Miner submitted share more than once" messages in your logs. Set '/' lower than current p2pool share difficulty and its meaningless. Set it above current p2pool share difficulty and even if your miner finds a share that would satisfy the requirements and end up on the chain, it will not be counted unless it also meets the difficulty requirements you set by using the '/' parameter. The benefit of this is that each share you DO submit is more heavily weighted than the "normal" shares, so it's worth more. At this point in the game, unless you're bringing a few hundred TH/s onto a node, there's no need to use this parameter at all. |
|
|
|
|
Another week in the books. Let's take a look at the results. Also note that this week there's a third miner in the tests. I pointed one of my S3s to mine on nastyfans.org's standard p2pool payout.
My standard p2pool node - 0.03205607BTC
OgNasty's standard p2pool node - 0.03861873BTC
NastyPoP p2pool - 0.02812263BTC
Expected - 0.0388BTC
Surprisingly, the miner I have pointed to OgNasty's p2pool payouts fared the best this week. I fully expected it to do worse than the other two because of the fact that the BTC address was completely new to p2pool, so ramping up some shares should have played a part. Instead, it performed much higher than expectations. I posted screenshots on 12/28 that showed the miner had found a higher than expected number of shares, which in turn translated into higher than expected payouts when blocks were found.
In general p2pool's luck was pretty awful this past week (coincidence.com shows 7 day luck of 73.17%), so it's not surprising every miner missed the expected payout mark for 440GH/s over 7 days. The one that came closest was the new miner I added last Friday.
The OP is updated with the results.
|
|
|
|
my water heater just blew up, so I'm busy getting rid of the excess water and cleaning things up.
Sorry to hear that. Starting next week NastyPoP payouts will start seeing a bonus from 250 NastyFans seats. Donations to NastyPool Update:
I've decided to redirect distributions from the 250 seats I had going to NastyPool. Instead of continuing to save funds for a future lottery, these distributions will now be donated to the NastyPoP address to provide additional BTC for NastyPoP miners.
That's a pretty cool way to distribute those funds. Nicely done! I just got everything all set back up and fired up the miner again. Thanks for the well wishes on the water heater. At least I caught it early and was home when it happened... boy that would have been an absolutely awful mess had I been away! |
|
|
|
|
Quick update... I've had to power down my miner on the standard p2pool payout for a few hours today... it's in the basement and my water heater just blew up, so I'm busy getting rid of the excess water and cleaning things up. Once the new water heater has been installed, I'll fire it back up. That's why you're going to see the drop in hash rate on the graphs (if you're looking). The miner on the NastyPoP payout is upstairs on a different circuit, so it's still up and running.
|
|
|
|
|
Mining BTC with a GPU? Maybe a couple years ago...
|
|
|
|
Update: Make that a half dead dud........  Awww man... that sucks . Hopefully Bitmain will hook you up with a speedy RMA and a bit of compensation (good luck with that, by the way). |
|
|
|
I think this is relevant: http://www.reddit.com/r/Bitcoin/comments/2qmrh8/bitcoin_093_came_out_in_september_but_still/The question: Bitcoin 0.9.3 came out in September but still doesn't even make up 50% of the network. Why? (self.Bitcoin)
As far as I know there is nothing controversial about 9.3 and yet it has been rejected by over half of the network. What is happening?
It seems weird if the answer is just laziness. Someone that runs a bitcoin node would presumably be a person that is fairly deep into bitcoin.
Is this effect a thing we are going to start to run into issues with? If non-controversial branches are failing to hit 50% is there a big risk that a branch that had more far reaching changes would struggle? Or is the consensus that all these updates are worthless to the normal person and a big update would excite the crowd into action?
Theymos's response (which I agree with): Older versions are still supported, and they still contribute to the network. 0.10 can efficiently download the chain from nodes as old as 0.3.18, for example. Each new version tends to add a few new protocol features and improvements, but it's not necessary for everyone to upgrade. In fact, it's probably good if the majority of the network doesn't upgrade for several months in case the new version has a serious bug.
I don't think it is a huge concern short term, long term if there is a problem we will have to figure out how to get it fixed... When the 0.9.x core was released, there was that whole heart bleed issue. A lot of people never bothered upgrading from the 0.8.x version because of this. |
|
|
|
|
Show Posts
