Not a problem.  I figured it was some growing pains putting Con's pool on a p2pool backbone.  I have faith they'll sort it out.  I just wanted to mention and display the connection issues when I saw them as they may have an effect on this week's test results... Not to mention bring it to your attention

Holy back to back blocks Batman!

Quick update... I noticed the S3 I had pointed at my own p2pool node has gone down.  Unfortunately, I'm away from home this week traveling for work and I do not have remote access to my miners.  I really should set that up .

Anyway, I will not be including numbers for that miner in this upcoming Friday's results.  I will have only 2 on the test: the miner on NastyPoP (which, I switched over to the new protocol on Sunday) and the miner on the standard p2pool payout.

Speaking of the new protocol (ckpool on port 3334 using p2pool as a backend), I've noticed very inconsistent hash rate, with a number of times connectivity has been lost altogether.  I'm guessing it's growing pains as nonnakip just brought this online recently.  Hopefully things settle down shortly.  We'll see what impact, if any, this has come Friday.

Here is a screenshot of the hash rate graphs from nastyfans.org showing my two miners:



Here's another miner using the NastyPoP method:



As you can see, the miners using NastyPoP show some pretty erratic hash rates and loss of connectivity, whereas my miner on the standard p2pool payout is straight across the board.

You're still mining all of those coins?  Wow... I stopped everything except for NMC.  Sure, I've got a boatload of some of those coins, but nowhere to do anything with them.  Like FSC... I've got a few million of the things, but the coin's completely dead in the water and no exchanges trade it.

I'd like to see p2pool's flaws addressed as part of that rewrite .

LOL... I'm going to guess 9:37am server time!

So... massive increase in memory usage and increased GBT latency... yeah, sounds like pypy is the answer... /sarcasm

Another week in the books, and it's a win across the board for the NastyPoP payouts.  The miners on the standard p2pool payout suffered some pretty bad luck finding shares and missed a number of payouts because of it.  The miner on NastyPoP was paid out for every single block.  P2Pool itself did abysmally this past week with a 7 day luck value of only 62.25%.  That, combined with my miners finding fewer than expected shares led to the following results:

My standard p2pool node - 0.00419189BTC
OgNasty's standard p2pool node - 0.01805329BTC
NastyPoP p2pool - 0.02152612BTC
Expected - 0.0367BTC
P2Pool 7 day luck - 62.25%

There we have it folks - the first time in this test that the NastyPoP method resilience to variance wins the day.  OP has been updated with this week's results.

CEO of Spondoolies-Tech is flying coach class from Israel to Miami.  If this doesn't show upstanding character and frugality, I don't know what does.  He's not wasting company funds on private jets or first class accommodations, he's riding in the back of the bus with the regular folk.

Wish I could be in Miami this weekend, but work prevents me from being at the conference.  Good luck and best wishes, Guy!

You hope people will direct a bunch of gear your way, and you hope you happen to find enough blocks to keep them satisfied, and you hope you have everything secured so your pool isn't compromised and you hope your servers don't crap out and you hope your payout routines work properly and you hope nobody's running block withholding attacks and ... yup, pretty much what you said

I want to build my own car but I have no clue how I should do it.  Who wants to take a ride in it?

Hey kano,

Just wanted to stop by and wish you well with your promotion.  You and Con have done a great service to the community by providing both great mining software and more recently your mining pool.  To everyone who is mining here, best of luck on winning the SP20!  Don't have to worry about me... my miners are still all hooked into my p2pool node and I'm traveling for work without remote access to change them

lol... perfect

Ingramtg, unless you've got some incredibly compelling reason to start your own BTC mining pool, I'd recommend against it.  Running your own p2pool node is relatively easy and gives you the power of running your own pool.  You just happen to be connected to a whole bunch of other nodes all working together to solve a block.

30-40 TH/s?  Try 300-400 to expect to find a block within a decent timeframe by solo mining.  At current difficulty, 300TH/s would expect to find a block a week give or take - so you'd likely find 2 blocks before difficulty rises again.  On average, a miner with 30TH/s on a pool would expect around 0.3431BTC a day, currently.

Are you asking about how long you would expect 7TH/s to find a block solo mining?  If yes, that's easy to calculate:

43971662056 * 2^32 / 7000000000000 / 86400 = number of days expected to find a block.  So, 312.26 days at current difficulty.

If you're asking about p2pool, that's a whole different question.  You get paid for every valid share you have on the chain when p2pool finds a valid block.

Using the same formula, you can calculate expected time to find a share...

10616061.28 * 2^32 / 7000000000000 / 86400 = 0.075 days = 1.81 hours.  So, you would expect to find about 13 shares a day.  Shares are weighted depending on network difficulty when found, and those weights are used to determine your payout when the block is found.  Realize that the share difficulty retargets constantly depending on perceived network hash rate, as does the expected time to block.

There have been a number of people trying to do something about it.  If you look at the thread I linked to the test I'm running, you can see how OgNasty approached it.  Quick summary: he put a traditional pool on top of p2pool's backbone.  It's an innovative approach, but the solution reduces variance by centralization.  You're forced to stay on his node if you want the variance reduction offered.

Bitmain came out guns blazing a number of months back with their antpool claiming they were going to revolutionize p2pool.  Yeah, that went nowhere.

A few of us suggested using side chains or some other method of managing variance.  That hasn't been implemented yet, either.

So, all in all, things are kind of at a standstill.  Nobody's produced a solution that has been incorporated to p2pool base code.  Bitmain forked the code, but hasn't done a thing with it in months.  OgNasty (well, actually it's Nonnakip who's written it) front end is completely proprietary and written in C.

Wish I had better news for you, but p2pool pretty much exists as it has.  If you don't mind the variance, or have enough hashing power to counteract it a bit, then go for it.  I'd say minimum entry at this point is 1TH/s.  I've got S3s and 440GH/s will miss the occasional block or 2.

EDIT: one other thing I forgot to mention... p2pool is written in Python and is single-threaded.  Can't scale very well on a single thread.

First, let me state that I'm a proponent of p2pool.  I run my own nodes.  I have contributed code to folks.  I have spent a ton of my time in these forums on the p2pool threads trying to help others.  I have mined on p2pool for just shy of a year.  Having written that, let me explain why p2pool doesn't have more of a following than it does.

1) P2Pool has a pretty large flaw in its implementation, which has been alluded to here on this thread.  The larger the pool gets, the more variance the miner experiences.  This is exactly the opposite effect of a traditional pool like Con's pool.  The larger that pool gets, the less variance.  Why does p2pool have this problem?  Because of the share chain that p2pool relies upon to pay miners.  In effect, the share chain is nothing more than an alt coin that you are solo mining.  The more hash rate thrown at it, the higher the difficulty becomes (just like Bitcoin).
2) It's pretty freaking inconvenient to operate.  Rather than a nicely packaged up application, it requires you to install a number of dependencies to run.  Unless you're familiar with Python and its packages, don't bother with running a p2pool node.  Granted, there are a ton of public nodes out there for you to connect to, but ultimately you'd want to run your own node to truly decentralize things.
3) Lack of developer involvement.  The guy who wrote the code initially is prone to disappearing acts.  It's been quite some time since he's actively posted in the p2pool thread.  The latest commit he made actually broke the pool, and anyone who had updated needed to revert to a previous state.
4) Variance.  While I mentioned one side of the problem in my first point, here's the other side.  Because it doesn't have a very large following, p2pool block finding times fluctuate pretty wildly.  Combine that with your own miners' luck in finding shares and you can get some pretty wild payout swings.  If you want to see a real-world example, check out the test I've been running here: https://bitcointalk.org/index.php?topic=891298.0

Hope this helps.

I get the concept behind it, and you cited precisely the example I was thinking about in my head.  However, this example still fails to benefit the node owner because the mining address is constantly cycling, which still means the node owner's address is ramping up on shares.  Sure, I suppose at the end of the day it would add up to the same thing - you'd just get a whole bunch of per share payouts to your node's cycling addresses instead of a larger payout to a single address.  However, that increases your transaction fees for spending those coins in the future because there'd have to be far more inputs.

Like I wrote, I just don't see how this could possibly benefit anyone except for the most paranoid tin-hat wearing folks running their own nodes.  For example, I run my own node locally, as well as a VPS-hosted node for backup when I travel.  I also fall back on your node in case neither of mine is available.  On my own nodes, sure I could put in something like a name of "S3_1" or "SP20" for each of my miners; however, configuration for your node forces me back into using a proper BTC address (which does not cycle)... unless of course I wish to donate my hashing power to you

While I understand the concept of rotating addresses, I don't understand how it's useful here.  Let's say that this was properly implemented in p2pool.  Who does it benefit?  As a miner, I still have to connect to a node using a BTC address.  I can't change that address constantly, or I'd always be ramping up shares on the chain for payout, which is exactly the opposite of what I want in a PPLNS pool.

What am I missing?

Glad to help.

You and me both

If Bitmain builds the S6 based on their new BM1384 chip, which I imagine they will, I'm guessing it'll be around 3TH/s @ 1400W.