[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[windpath]

...
PPLNS (p2pool's payout method) by design discourages pool hopping, pretty successfully. While your not technically hopping, it will have the same effect for you.
...

False.

PPLNS has no expected effect on reward for hopping miners.

Edit: the thread title means hopping isn't statistically expected to gain anything, but it wont lose anything either.

If you read OP you'll note he is buying large short lived mining rental contracts on p2pool, on his last big contract we/he happened to mine a very lucky block that likely paid every share he had in the chain from that rental.

While I'm enjoying our current luck, one thing I know is that it's bound to change...

Hence while he likely just had a very profitable run with our lucky block, that will not always be the case (rent multi-PH of rigs, find a block just after the rental expires).

The highest probability for the best reward is clearly to stretch out the mining to at least include 1 expected block, if not several.

[SixOfFive]

OP also stated the last month and a half .. not the last block.

I'm not going to explain my reasons, or when and why I slam the hashrate in there... but this experiment works so far... I will let you speculate as to why as you can see my spikes of hashrate.

I will not deny though, that there was a 7.5phs run that was not mine... No idea about that, but the majority of the spikes over the last while have been me.

Edit: Me and my friend

[kano]

...
PPLNS (p2pool's payout method) by design discourages pool hopping, pretty successfully. While your not technically hopping, it will have the same effect for you.
...

False.

PPLNS has no expected effect on reward for hopping miners.

Edit: the thread title means hopping isn't statistically expected to gain anything, but it wont lose anything either.

If you read OP you'll note he is buying large short lived mining rental contracts on p2pool, on his last big contract we/he happened to mine a very lucky block that likely paid every share he had in the chain from that rental.

While I'm enjoying our current luck, one thing I know is that it's bound to change...

Hence while he likely just had a very profitable run with our lucky block, that will not always be the case (rent multi-PH of rigs, find a block just after the rental expires).

The highest probability for the best reward is clearly to stretch out the mining to at least include 1 expected block, if not several.

P2Pool is (almost) hop-proof due to using PPLNS but does not victimise hoppers.

You CAN'T change the probability of a share being rewarded vs the amount it is rewarded.
If there are more shares in the next payout, they will be rewarded less each, but the expected number of payouts of course increases with the increase in the number of shares.

P2Pool currently has a perception problem due to the fact that only a small % of your shares get a reward.
But you can't decide which of your shares will be rewarded, that's purely based on the luck of block finding.
There's no magic memory in any pool that decides, because you found a block now, when the next one will be.

Another way to look at it would be this:
If p2pool does victimise hoppers, you could increase your expected reward by DDoSing the largest p2pool node ... ... ...
... ... ... fortunately that's not true.

[KorbinDallas]

OP also stated the last month and a half .. not the last block.

I'm not going to explain my reasons, or when and why I slam the hashrate in there... but this experiment works so far... I will let you speculate as to why as you can see my spikes of hashrate.

I will not deny though, that there was a 7.5phs run that was not mine... No idea about that, but the majority of the spikes over the last while have been me.

Edit: Me and my friend

No need to explain your motives or strategy in my book. I'm just glad you're joining P2Pool! Welcome aboard the train 😀

[KorbinDallas]

OP also stated the last month and a half .. not the last block.

I'm not going to explain my reasons, or when and why I slam the hashrate in there... but this experiment works so far... I will let you speculate as to why as you can see my spikes of hashrate.

I will not deny though, that there was a 7.5phs run that was not mine... No idea about that, but the majority of the spikes over the last while have been me.

Edit: Me and my friend

Oh, forgot to ask; Are you renting from a public provider? Just curious

[SixOfFive]

Yes I am.. NH and MRR (always open to other rentals if I can ever find more lol)

[Meuh6879]

We have waves ...

[SixOfFive]

Yeah .. doing next phase .. It should look even better in a few hours

[Meuh6879]

[Meuh6879]

[Meuh6879]

[Meuh6879]

11 PH/s

[SixOfFive]

Funny .. this is the warmup to preheat my wallet

[windpath]

Funny .. this is the warmup to preheat my wallet

Well your warmup consists of the highest hashrate we've seen since I've been tracking

[SixOfFive]

Its not just me .. somebody is piggybacking and bring some hash with them as well lol ... heads up! if your watching here, I'm winding down for 2 hours before I do my final push!

[SixOfFive]

Just can't seem to gather enough hash rate to push above 10phs ... Market just doesnt want to co-operate over the last day

[Meuh6879]

  well, if you are a professional ... you can not "test" for a long day without profit.
the mining industry is like that.

and it's good, trusted mining is profit mining.

[in2tactics]

We have been on fire this last week!

However, I am still trying to figure out why we historically get so few transaction fees. I look back at the blocks we solve and the blocks surrounding ours are almost always >900kB. The last block we solved, block 435656, was only 20kB. I am betting kano is going to jump in on this and say something like, "People do not configure their setup properly. That is the problem you will always run into with p2pool." In any case, I think we should attempt to improve this somehow. Any ideas?

[Meuh6879]

We have been on fire this last week!

[jonnybravo0311]

We have been on fire this last week!

However, I am still trying to figure out why we historically get so few transaction fees. I look back at the blocks we solve and the blocks surrounding ours are almost always >900kB. The last block we solved, block 435656, was only 20kB. I am betting kano is going to jump in on this and say something like, "People do not configure their setup properly. That is the problem you will always run into with p2pool." In any case, I think we should attempt to improve this somehow. Any ideas?

You're spot on with your reasoning.  Knowing how to set things up properly plays a large role in the composition of the blocks you create.

In a more typical pool model (like mine, kano's, etc) a single source provides the workload for all miners.  You as the miner don't have to know anything other than how to configure your hardware to point to the pool.  Details of block size, block composition, etc are all managed by the pool software and the pool operator.  With p2pool, when you are running your own node, you must also learn how the blocks are created.  Ideally, you should understand the code - how it creates blocks, how often it changes the block composition, etc.  For example, what happens in the p2pool code when a block is found on the network?  How does it invalidate the transactions on which miners are currently hashing?  Does it produce an empty shell and push that to miners?  Does it fully validate the new block?  What are the optimal block size settings that will be most efficient for your p2pool node?  What kinds of transactions should be in any blocks it creates?

These are just some of the things a pool operator needs to know, regardless of whether or not that operator runs a typical pool like myself, or a p2pool node.  The reality is some pool operators don't have the foggiest.  This applies to both models - I'm not singling out p2pool here.

In a nutshell, on a pool like mine or kano's, the burden of this knowledge is ours to bear.  We tune our pools as best we can to produce full blocks with lots of transactions and fees.  For example, kano ensures that all of his own pool's transactions are included in the work given to his miners.  Why?  Because it allows him to confirm the pool's miner payout transactions, which might otherwise not be picked up by other pools.