The size of a miner is completely irrelevant.  Hash is hash.  There is no such thing as a miner draining the pool (unless he's purposefully withholding blocks), or for that matter a smaller miner somehow making a larger miner's hash less wasted.  Miner 1 has no impact on the probability of miner 2 hitting a block, regardless of the hash rates of either miner.

Remember... that guy with 1.4PH could have a warehouse with 100 S9s, or 234 A721s, or 1273 S5s or 3091 S3.  His hardware is no different than the guy with a single S3 in his basement... he just happens to have a whole lot more of it.

Wow... great luck!

The "+" is pseudo shares.  The node will accept shares at this difficulty from your miners.  The lower the value, the smoother the hash rate graphs become.  No value otherwise, and increases the network traffic.  Basically, you are overriding the variable difficulty set by the node with your own static difficulty setting.
The "/" is share chain shares.  The node will only submit shares to the chain at the given value or higher.  Even if a share meets the minimum share difficulty, the node won't submit it unless it also meets the target difficulty set by you.

Congrats on the pool's first block

Typically the mining pool will make the decisions on what transactions to include in a block.  The miners are simply hashing headers.

If you want to have control, you can run your own p2pool node.  This will allow you to make your own decisions about which transactions you want to include in the blocks you create.

Did Zed try doing just the opposite?  Setting up his worker as BTCADDRESS/1 or something (that setting will force minimum difficulty shares, not actually diff 1)?  Also, I know there was a p2pool fork that had difficulty determined by individual workers, not by the node itself.  I forget who wrote it...

The whole point of the "/" parameter was to prevent exactly what's happening on your node... where one very large miner effectively shuts out small miners.

For example, looking at p2pool log data from when I last ran a node (yeah, I still have those old logs ):

The "Difficulty" comes from using the "+" parameter.  The "Share difficulty" comes from using the "/" parameter.  In the case above, I used "BTCADDRESS+500".  Since I didn't use the "/", that worker's difficulty was calculated to be the share chain difficulty.

To determine the share difficulty, the code checks to see if you've passed in a value using the "/".  If not, it'll determine it based your node's hash rate vs the total p2pool hash rate and compare that to the minimum share difficulty to get a share on the chain.  If lower than the minimum, it'll use the minimum.  Else, it'll use the value obtained from the comparison.  However, if you do pass something in "/", it'll use that value (unless it's lower than the minimum share difficulty, in which case it'll use the minimum).

By doing these calculations, p2pool as a whole tries to prevent a single actor from flooding the share chain.  However, by providing the ability to override it, I'm not sure how effective a strategy it really is.  Hence the numerous debates we had in the past .  On the one hand, p2pool tries to ensure no one actor can adversely dominate the chain.  It does this by increasing the share difficulty on the node to compensate.  This works great if every miner runs his/her own node (which is truly how p2pool was envisioned to be utilized).  However, on the other hand, it fails when you have multiple differently sized miners on a single node.  Now the poor small guy gets to suffer some pretty nasty variance because the share difficulty is far larger than the hash rate would warrant.

The "official" solution was to offer the "/" parameter, so that all miners on a node could manually override the node's set difficulty.  As I pointed out earlier, this means a non-scrupulous actor with a comparatively large hash can override to use a minimum share difficulty and flood the chain.  Eventually, the entire p2pool network catches up, though and the overall minimum share difficulty is raised to match the new larger hash rate.

That last sentence is yet another area we've debated countless times, and exposes the largest flaw in the p2pool design: the more hash rate the pool gets, the more variance the miners suffer.

In a typical pool setup (like my pool), the more hash rate the pool gets, the less variance each miner sees.  This makes miners happy because they get statistically closer to the expected daily payouts the online calculators show.  in p2pool, the more hash rate, the higher the minimum share difficulty, and the fewer shares you'll have on the chain to be paid.

In an extreme example, imagine all the network was on p2pool.  The current diff is 310,153,855,703.43, which translates into one block every 600 seconds.  P2Pool strives to get one share every 30 seconds.  Therefore, if every miner was on p2pool, the minimum share difficulty to get a share on the chain would be 15,507,692,785.1715.  Imagine that.  An S9 would take about an expected 55 days to even get a single share on the chain.  Talk about variance!  Using that same example, let's assume every single miner was on my pool.  A block would be found every 600 seconds.  The miner with the S9 would make a consistent 0.01135BTC a day.  Yes, I purposefully ignored luck factors in the two examples.

My pleasure... I ran p2pool nodes for a few years .

You can use them in conjunction with each other... like:

The "+" is for your stats.  There are a number of old threads where the value of using it is debated.  My opinion is that it only helps smooth out hash rate graphs on the node.  The lower you set it, the more "pseudo shares" the node recognizes as valid work, and the smoother your hash rate appears on the graphs.  Those lower diff shares don't get added to the share chain (unless of course they satisfy the share chain diff).  The downside of this is that you are flooding the node with a whole boatload of useless information. 

The "/" actually helps the node for the reasons I mentioned in my previous post.

You can actually help the miners on your node.  Right now, you are relying upon the node to determine the share difficulty it will accept.  Standard p2pool code will base the difficulty on the combined hashing power at the node.  When there is a great disparity (like yours), the smaller miners are subjected to a much greater variance.  Sure, each share found is weighted higher, but the larger variance means the small miner might miss out on payments because they don't have any of the heavily weighted shares on the chain.

The solution is easy, and is something you can do to help.

P2Pool allows a miner to determine his own share difficulty.  This will override the node's setting.  You implement this by using a "/" at the end of your BTC address.  For example, if you want the node to only accept shares from you above 100,000,000, then you would put the following as your username:
This way the other, smaller miners on your node aren't penalized.  The node won't count your hash rate in the calculations of share difficulty.  Now, the smaller miners will find more, less-weighted shares, and you will find the more heavily-weighted shares.  Everyone wins.

Whoever is trying to mine to the pool using a BTC address, please create an account and workers.  The pool does not support direct mining to BTC addresses.

Also, let's do a holiday promotion!

With BTC prices topping out over $900, now would be a great time to get a little extra.  From now until the end of the day on Christmas (23:59:59 EST 12/25/2016), anyone who finds a valid block will receive a 1BTC bonus from me.

Good luck to all

Perhaps it was the mention of chicken?

Your very first sentence makes an incorrect proposition.  Firstly, you have no idea when you would have found a block.  For discussion, let's assume that you are basing this on expectations, and at 99.999% of expected shares you change the coinbase transaction address.  That very next share has just as much of a chance to find a block with the new block composition as the share before it did on the old block composition.  Changing that address means absolutely nothing.  There is no such thing as "wouldn't find a block for the next N amount of shares."

If you went trillions of shares without finding a block, that's not because you didn't do something like change an address.

Pools are ALWAYS changing the composition of the blocks they are working on.  The work they pass on to the miners is therefore also always changing.

Perhaps I can simplify it for you a bit.  You keep bringing up the 666% block.

For those hashes, statistically you would have expected to find 6 blocks.  It simply does not matter if the coinbase transaction distributed the block reward to address 1, address 2, address 3, ..., address N, or to all of them (like in p2pool).

What would have happened had you been mining to address 2 instead of address 1?  You would have expected to find 6 blocks.  That's it.  Changing the address(es) in the coinbase transaction has no bearing at all on those expectations.

I hope that helps to clarify it for you .

Yup.  I'm aware that on your solo pool, you can in fact determine the address of the block finder (it's the one that's not your address ).  However, to know that, you still had to do some deduction, or you used one of the block explorers and let that tool do the work for you.

In some cases (like yours) you can very easily determine who mined the block by doing some simple analytics.  However, in other cases, that information is just not available.  Yes, I know that kano's pool solved block 444154.  I certainly do not know which of the miners on his pool submitted that hash.  Same on p2pool... one of those 154 addresses in the coinbase transaction of block 443907 found the block... but unless I'm subscribed to the p2pool channel in IRC, I have no clue which one it was.

Anyway, thanks for correcting my blanket statement

Statistically, you should have found 10 blocks given your scenario.  You didn't find any.  Is it possible?  Yes.  However, it is extremely unlikely.  In fact, if you calculate the CDF, you will see just how small a chance a 1000% block is.

Looking at the next argument of changing the address that found the block, I'd like to get some clarity.  What are you talking about?  What do you mean by "the address that found the block"?  There is no record in the blockchain of the miner who found that block.  Sure, a pool might put their name in the coinbase transaction message (in fact, most do), but nowhere in the block itself does it say, "this block was solved by jonnybravo0311".

For the sake of the discussion, I'll assume you mean you're going to change an address in the coinbase transaction.  If this is the case, then your statement about the same hash not solving the block is completely accurate.  It's why the statement, "boy I sure wish I were solo mining" when people find a block on a pool is just silly.  That same hash would NOT have solved the block in any scenario except for the exact one in which it did.

This brings us to your conclusion that you've changed your luck by manipulating the contents of a block.  No, you absolutely have not.  6PH is 6PH.  What the contents were when the hash was calculated has no bearing on your luck.  Either the hash worked with that set of transactions and the block was added to the chain, or the hash didn't work and no block.

As I wrote in my first reply in this thread, there's no secret sauce.  It is what it is.

Pools are a group of miners that work together to solve the block.  The reward is split amongst the miners.  Because the chances of finding a block by yourself are remote (unless you happen to have petahash of gear), you join a pool.

Your thread title is very misleading.  I'm not sure how you consider this solo mining, as it most certainly is not.  You have a p2pool node.  Sure, you might be the only person on your node, but just because you're solo on your node, you aren't solo mining.

Yes, you can hack the p2pool code to not connect to the rest of the p2pool network and make it a true solo mining operation.  However, that's not what you're doing.

Also, you made 1.5BTC because p2pool happened to be lucky during your rentals.  There's no magic formula behind it.  You could have just as easily not made anything at all during your rentals.  You got lucky, plain and simple.

I'm happy for you that you made back a nice little bit of profit.  It sure feels good.  Please don't think you've discovered some secret sauce, because unfortunately, you haven't.

As long as whatever you're doing keeps you happy and mining, hash away and enjoy it .

Your correction is also wrong.  Your are getting 3.8TH/s... or 3800GH/s.  you most assuredly are not getting 3800TH/s from an A6.

Congrats on the block find!  Nice fat one, too

I finally got around to implementing the code to support segwit.  I have tested it thoroughly on the test network and it produces valid blocks.  I tested it with a bunch of different transactions through multiple blocks including segwit to segwit, non-segwit to non-segwit, non-segwit to segwit and segwit to non-segwit.  Transactions also were comprised of multiple inputs and outputs, single inputs to multiple outputs and multiple inputs to single outputs.

Should segwit activate on the main network, we are good to go.

Now let's find some blocks!

Sure thing.  Glad to help.