Certainly, a larger block size has its merits.  However, the fear that the blockchain could fork is causing some people to scream that the sky is falling.  Truthfully, why shouldn't investors be scared?  Unless the core developers come to a consensus, then it comes down to who adopts what.  If the majority follow the XT crew, then bigger blocks (and all the other stuff in XT) come into play.  If the majority follows Core, then things remain as is (barring any other improvements that are agreed upon and added).

How much free power do you have access to?  When will somebody realize that you're utilizing a ton of their power?  Plugging in one S3 might go unnoticed.  Plugging in an S5+ is going to attract attention.

I am looking forward to a new piece of kit as well.  I passed on the S5, as well as the SP20 when they launched.  I'm still running my old S3s as they've long since paid for themselves and still manage to eek out a tiny bit of profit.  They obviously won't last forever - in fact, they've gone about 7 months longer than I anticipated they would thanks in large part to the minimal difficulty changes this year.

It only affected the NastyPoP nodes for the vast majority of the few days.  The NastyP2P nodes were only down for a few hours.

It's almost not even feasible for datacenter operations either.  Sure, it's about the size of 3 S5s tied together, but you're not going to be able to rack these things... so it's open shelving for them.  Oh, and at 3436W from the wall... and with Bitmain explicitly stating not to use multiple PSUs per board, means you're going to have to either throw 3 EVGA 1300G2's per miner, or if you're getting more than one, you can use those IBM Server 2880W PSUs - 1.5 of them per miner.

Most certainly not a home miner though...

For p2pool, it is up to the node operator on whether or not to support XT.  This is of course assuming that forrestv's code can handle the larger block size in BIP101.  He had to make changes to the code to support BIP66 (bumped up the version of p2pool from 13.xx to 14.xx), so I'm not sure if similar changes would need to be implemented to support BIP101.

However, assuming that the underlying p2pool code can indeed handle the larger block sizes, then it will be up to the node operator to choose whether or not to use the XT code or the Core code to generate the blocks.

P2Pool's luck certainly turned around this past week.  Both NastyPoP and NastyP2P beat expectations by quite a bit.  NastyPoP would have done better, but it appeared that the nodes were down last weekend.  My miner failed over to a backup pool.  I'm not sure why the pool was down (both OgNasty's and TheAnalogKid's NastyPoP nodes were offline), but the result is that the payout was less than it should have been given the number of blocks p2pool found.

8/7 - 8/14
NastyPoP: 0.03914884BTC
NastyP2P: 0.07990332BTC
Expected: 0.02941349BTC
Luck - 241.06%

OP updated.

Those are two different and separate parameters, with different functions.  The "+" is the pseudo-share difficulty.  It's primary function is to provide you with feedback.  If you look at your miner logs, you'll only see accepts for shares greater than the value you use here.  The lower the number, the more shares you submit, the smoother the graphs become.

The "/" parameter is actual share difficulty, and its functionality is as I described in my previous post.

Typically when your expected payout drops way down, it's because you're either finding fewer than expected shares (variance) or the shares you are finding are orphaned or DOA.  Also, take a look at the node on which you're mining.  If the node's hash rate will lead it to finding a lot of shares, the node will adjust the share difficulty up to compensate.  You can counteract this by using the "/" parameter in your miner user name:
This will tell the node that no matter what it determines the share difficulty to be, you want it to accept shares of minimum network difficulty from you.

I have 8 S3s that I run from my home.  I also have some cloud mining contracts and I rent hash from time to time.

So the Mac binary for XT is pretty poorly put together... it's not even an app, it's just a compiled tarball with some executables in it.  I might have to rectify that.  Of course, I'll have to get by the configure file claiming I don't have BDB, even though I do - and it's in the standard location - and can compile Core without issue.

Compilation from source on Ubuntu went flawlessly.

I will probably test this out on my node... but won't get to it today.

Username: jonnybravo0311
Member Rank: Hero
Post Count: 2474
BTC address: 1DevLdogN52pHdjZnsgi4HzreFDB4ZHVre

Unless the changes forrestv recently made to support BIP66 also include support for BIP101 and the far larger block size, even if you are using an XT node, wouldn't you still be restricted?  Also, assuming the p2pool code does indeed support the larger blocks... what happens when any p2pool node on XT happens to find a block that is too large for inclusion on the blockchain?  Wouldn't the rest of the network reject it?

So, my contract has completed, and I thought I'd share my thoughts here.  When I initially bought my contract, I did so with a coupon code I had received offering me a discounted price.  So, I purchased a 1TH/s SHA256 3 month contract.

Shortly after my purchase, Mintsy changed their contracts, and upgraded me from 1TH/s to 2.5TH/s, also extending my contract duration.  At this point, I was quite happy with the service.

I tried a few of the options available to me - using Mintsy pools, my own external pools, etc.  I didn't have much luck getting external pools to work, but the Mintsy BTC pool worked just fine, so that's where I kept my contracted hashing power.  I also tried to use my own hardware to mine at the Mintsy BTC pool.  Relaying through MRR didn't work at all; however, just pointing my gear directly at the pool worked out alright.

So... where did things go wrong?  It wasn't for a while into my contract until things started to go awry.  Where my hash rate had been very consistent early on, it spiked wildly.  Hours would go by where no hash rate at all was reported, then it would spike up to some higher amount for a bit to attempt to compensate.  Well, I wasn't too bothered by this because even though the graphs were showing bursty traffic, the average was close to the contracted amount.  Unfortunately, then the payouts were way off.  Even though I should have been credited for what my average hash rate was showing, the payouts didn't come close to reflecting that value.

I opened a number of tickets with support to explain my issues.  I would typically receive a quick reply, even if it was a canned response about being compensated at the end of my contract if necessary.  My biggest problem with support was that they were quick to reject any reported problem.  For example, when I reported my hash rate and earnings were far below what was expected, I was given the canned answer of "sometimes hash rate dips below contracted rate".  When I supplied proof that this was more than just a dip (it had been going on for nearly a week), I was then told that it wasn't possible for me to predict my earnings.  Why is it that I'm the one responsible for a bitcoin mining operation's support team's education?  What do you mean I can't predict earnings?  Every online calculator out there predicts earnings.  The formula for calculating expected earnings is readily available.  Finally, after providing evidence of my actual payouts vs expected payouts, and how I arrived at my expected payouts value, I was told there was a problem with miner reporting and that I'd be compensated.

Unfortunately, things never really recovered.  Hash rate was still swinging all over the place.  Graphs reported a large percentage of rejected shares from my contracted hashing power.  Payouts were well below what I should have received.  Basically the entire month of June the payouts were far below what they should have been.  Towards the end of my contract, the pool's hash rate began to drop.  It went from a peak of over 7PH/s down to where it is today, averaging about 20TH/s.  Since the hash rate dropped so significantly (all during the month of July it dropped), there were very few blocks found, and hence very little payout - although the payouts I did receive in July were right about what I would have expected for the hash rate I had.

It's too bad this didn't work out.  The service offered some pretty promising features had it been able to deliver.  Unfortunately it couldn't, and for that reason, I cannot recommend it.

By the way, here are the actual numbers from my experience:

Contract purchase price: 2.17543320BTC
Contract total payout: 1.55217135BTC
Net profit: 0.62326185BTC (red indicates a loss)

Pros

• Clean UI/UX
• Ability to point your contracted hash wherever you want
• Direct integration with Cryptsy based on your trade key

Cons

• Wildly fluctuating hash rate
• Payouts inconsistent with average hash
• Mining to an external pool was flaky at best - some worked, some did not
• Support team too quick to give canned response and dismiss ticket

Overall rating: 2/5

They just yanked that data from blocktrail.  And, the article is pretty full of errors.  Describing ck.'s solo pool as people pooling their resources to find a block faster, but only the block finder gets the reward is completely wrong.  Then they just cut/paste the same thing for kano's pool.  Also, p2pool.org?  That's not even a node... it's an information site run by windpath.

Statistically even your CPU will eventually provide such as share as well, or even one that solves a block... or it could produce it in the very next second.  Of course, you've got a far better chance of it happening when that stick is hashing a thousandfold faster than the CPU is

Hopefully they'll actually sell that gear to people when it's introduced... granted, I haven't kept up with them much recently, but last I remember they stated they weren't going to produce miners for consumer sales after the SP20.

This should provide the answer for you: https://www.blocktrail.com/BTC/pool/solockpool

Pretty sure that's the basis of what nonnakip and OgNasty have done for their NastyPoP implementation.  Every miner connects to the ckpool instance, which directs to the p2pool node underneath.

Where are you seeing the address that provided the block solution?  My logs don't show that information, they simply show this:
I suppose I could evaluate the share data ... but that wouldn't work for any blocks found by dead/orphaned shares...