Giving up real solomining and going back to solomining on p2pool

[Biffa]

From the timing of when he mentioned it, it looks like that may very well be a possibility, appears to have happened within minutes of biffa mentioning it... Thanks biffa!

There's the secret sauce! And I thought that only worked on Kano's pool!

Its not because of the chicken, its because I can't sit comfortably right now.

[philipma1957]

I just thought of something.

The op has said he had better luck when he rented 10th

He may be correct.

Here is why  a 10th rental  most likely does not have an s9 involved  since most s9's at at least 11th.

Kano has some stats that show the older s9's suck and have really bad luck.

If old s9's suck and have bad luck due to code.  then renting in 10th sections will be better.

but nicehash now forces you to rent in 50th blocks soany chance of avoid an s9 is no longer possible.

So after my rentals finish with nice hash I will no longer rent with them.

Unless they allow 10th rentals again.

All people should not rent from nicehash and 256 hash unless 10th size is allowed.

So the op very likely  has found  back door proof that the older s9's have shit code.

[PublicP2poolNode]

Very interesting theory! I think it's sucks myself that they raised the minimum limit to 50th, I don't think me stopping renting from them would make them change their policies though as their is always someone willing to rent their hashpower even at 150 to 200℅ of expected return, there is always that idiot that likes to throw away their money.

I hate to admit it but I think me renting 600 orders at 10th each might have been the reason they changed it in the first place.

Even though I had an unlucky streak at the end i had several shares that came extremely close to finding a block, one of them even came within 1 billion of meeting the difficulty, ouch, that one hurt!

Wishing they'd lower their limit back to 10th!

[philipma1957]

Very interesting theory! I think it's sucks myself that they raised the minimum limit to 50th, I don't think me stopping renting from them would make them change their policies though as their is always someone willing to rent their hashpower even at 150 to 200℅ of expected return, there is always that idiot that likes to throw away their money.

I hate to admit it but I think me renting 600 orders at 10th each might have been the reason they changed it in the first place.

Even though I had an unlucky streak at the end i had several shares that came extremely close to finding a block, one of them even came within 1 billion of meeting the difficulty, ouch, that one hurt!

Wishing they'd lower their limit back to 10th!

yeah you may have taxed his servers down it.  but you did pay a small fee on every order  I think 0.0001

And you may have had the better luck with them  since the  s-9's are 11th to 14th

So my rentals will end with them as of today.

[PublicP2poolNode]

Maybe you should make a post on their thread to let them know that your not going to rent from them anymore and the reasons why.

[PublicP2poolNode]

Looking at the graphs today, it looks like it's currently my 10 orders from nicehash of 50th each, and a miner with 2th Mining on this node.

A few other miners mined for a few minutes with low hashrates under 1th who quickly left and I assume it's because the difficulty that is served to miners is pretty high since the node has a high hashrate.

I played around with p2pool a little when I first started mining a few years ago, but there weren't any places to rent from back then and after my first solo block on solo.ckpool.org I lost interest in p2pool for a few years.

Now that I have renewed interest in it and am able to rent hashpower in large quantities I am able to do more testing and research on it to better understand and fine tune my node.

With p2pools current hashrate a valid share needs to be around 1.2m but since my node is large compared to others the difficulty for a share on my node to be accepted by the other nodes in p2pools network is currently 30 times higher than it is on the smallest nodes.
Of course each share found on my node does have more weight than a share on the smaller nodes so it doesn't effect variance too much unless your a low hashrate miner on this node.

Currently with 10th, expectations are about 5 shares per day so variance is pretty good, you might find 7 today and three tommorow, but since the expectations for p2pool to find a block is currently on average of every four to five days, you should always have shares that are on the sharechain so that you get a reward from every block.

Looking at the only miner besides myself with 2th, I assume it's zed, he should expect to find about 1 share per day on my node, whereas if he set up his own node or mined on another node that was smaller he should expect to find shares more often although they carry less weight than when found on my node.

Looking at his chart, it looks like he found two shares his first day mining on my node which were paid because a block was found, but over the last three days no shares have been found with 2th. It appears those shared have now expired so hoping that your able to get another share before the next block is found.

If you want to find a smaller node you can look at p2pool.info and find a node with low latencies and better than average effeciencies.

My effeciency rate is currently 90% which I'm not happy with at all and am going to do a restart to see if I can get latencies lower and decrease stales/doa's

One other important note, when I restart my node any shares you have are safe because all nodes in the network have a record of all valid shares whether my node is on or offline. If you have valid shares when a block is found you will receive your rewards.

Edit: node restarted

[ZedZedNova]

Looking at the only miner besides myself with 2th, I assume it's zed, he should expect to find about 1 share per day on my node, whereas if he set up his own node or mined on another node that was smaller he should expect to find shares more often although they carry less weight than when found on my node.

That is indeed my 2th machine. When I pointed the miner at your node I started looking at p2pool stuff, and am, in fact setting up my own p2pool node.

I have set up a full bitcoin node which is in the process of syncing now, but seems to be taking forever or at least longer than I thought it would... When the sync completes I will start the p2pool node and point my miner at it. We'll see how that goes.

[PublicP2poolNode]

That's great zed! Also congrats on getting a share again! Crossing my fingers p2pool finds a block before it drops off the sharechain

[ZedZedNova]

yeah, looks like I got shares from ~6:30am - 9:30am (EST) when it looks like all of your miners had stopped. There was another break that looks like ~6:15pm - 8:00pm (EST) where I got a few more shares.

[PublicP2poolNode]

yeah, looks like I got shares from ~6:30am - 9:30am (EST) when it looks like all of your miners had stopped. There was another break that looks like ~6:15pm - 8:00pm (EST) where I got a few more shares.

That is correct, when my orders were outbid and my miners stopped hashing on this node, you were the only person left mining, thus the difficulty decreased exponentially.

Notice how when you found a share shortly after midnight while my orders were running again, that you were awarded ALOT more for that share than the shares you found while you were the only one mining on the node

The reason for this is that the other nodes raise the difficulty for my node when my rentals are working so they aren't bogged down with shares from my node.

But when shares are found on my node when the rentals are working they carry more weight and thus pay more than if you were on a node with less hashrate.

[jonnybravo0311]

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:

Code:

BTCADDRESS/100000000

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.

[PublicP2poolNode]

Currently each of my miners are set up like this:
Btcaddress+135000

I did this because when I am outbid on nicehash and my orders go dead, the work difficulty is lowered. Sometimes it gets so low that when my orders come back online the pool has been disconnected because difficulty is too low.

The only way I know how to fix that is to set the difficulty like I am currently.

I wonder if using btcaddress/difficulty would have the same effect as btcaddress+difficulty to keep my pool connection to nicehash live and also to reduce variance for the smaller miners?

I'll give it a try on Monday and see how it affects the node.
Currently after my latest adjustments from the oter day it looks like the effeciency is doing alot better than before but I want to run it a little longer to see if it is just a coincidence or not.

By the way, block found https://blockchain.info/block-height/444907

Edit: went ahead and changed them to BTCaddress/27000000 on 9 of them and left one of them at btcaddress+135000 so as to try and keep the pool connection live with nicehash.

Will see how it effects efficiency if at all but also to see how it affects the smaller miners. Again thanks for the input Jonny

[ZedZedNova]

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:

Code:

BTCADDRESS/100000000

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.

Thanks Jonny. That's pretty cool, and good to know.

I have not had time to dig into the P2pool code yet, but may have some time now that the holidays are upon us.

[jonnybravo0311]

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

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

Code:

BTCADDRESS+13500/100000000

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.

[PublicP2poolNode]

Got it

Changed all my workers to BTCaddress/27000000

Will see how it does. Thanks again, very helpful information!

[jacobmayes94]

First off I'd like to say that I'm impressed that this topic has brought in legendaries like yourself Philipma, Kano, and johnybravo to comment, very exciting

And I'm not saying that I know more than you guys, because I'm nowhere in the realm when it comes to writing code etc, I just wouldn't know where to start. I'm simply hosting a p2pool node near westhash for people who would like to rent from there to mine on p2pool and need a node that's close since latencies are very important on p2pool.

And I do agree that it's possible that nice/westhash has block withholders even though I can't prove it either even after spending 877btc using their service, in time of bad luck it always makes you wonder.

https://blockchain.info/address/3PvtPj8Zk2fGTjKfSNjjbxMGVfi6U52GW8

However I do disagree that changing the address that I'm mining to won't affect my luck whether that is for the better or worse.

Here's why. If I mine to the same address I can expect some very lucky blocks and some very unlucky blocks, I don't remember if it was Kano or CK who said that after 100 blocks you should be at or near 100℅, I think it was Kano who said that when he was taking about nicehash withholding blocks. But one of those two said that before.

So, with that said, if nicehash isn't withholding blocks then I can expect very close to 100℅ return after 100 blocks mining to the same address, doesn't it make sense then that if I change addresses after each block is found that after 100 blocks my average could just as likely be 0 as it could be 1000? And that it will be determined partly by my luck as to which addresses I picked and at what time I chose to use them?

I know the prohashing forums have also mentioned symptoms from nicehash of abnormally low 'luck' describing how shares that found blocks were not submitted

https://forums.prohashing.com/viewtopic.php?t=968&start=10

[PublicP2poolNode]

It's possible... Who knows In the past few weeks I've more than tripled my BTC renting hashpower yet none of the blocks have been found with my rentals. Of course I haven't spent enough to have expectations to have found a block yet either...

[PublicP2poolNode]

Got it

Changed all my workers to BTCaddress/27000000

Will see how it does. Thanks again, very helpful information!

update... Doing this did not affect zeds difficulty. He was able to find a few shares when my rentals went dead for a short while, but doing this does not appear to lower difficulty for smaller miners on my node.

Maybe a smaller miner who wants less variance can set it up with his miner to get shares more frequently. Although who knows which one will pay off bigger, could go either way.

Zed: maybe you should try btcaddress/3000000 to reduce your variance. Especially since my rentals come on and off due to being outbid. It may work out better for you.

[jonnybravo0311]

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 ):

Code:

2015-12-01 08:07:17.602682 New work for worker! Difficulty: 500.000000 Share difficulty: 1403930.065645 Total block value: 25.556069 BTC including 3236 transactions

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.

[PublicP2poolNode]

That makes sense, man it can get pretty complicated, so another thing I noticed was when I used btcaddress+150000/27000000 with westhash it completely ignored it and my shares I was submitting were around 42m at the time.

I then thought about "the unscrupulous actor" as you mentioned previously and didn't want to flood the chain with my shares so I changed my orders on westhash to BTCaddress/50000000 and again it ignored it.

When I tried btcaddress/27000000 then I was submitting shared at 27m, but not wanting to flood the chain again I changed it back to just my btcaddress only.

Where I see the biggest concern is that if zed for example doesn't set his own share difficulty then it might take a day or three days to finally get a share on my node, but if my orders go dead before he finds the share and the nodes share difficulty drops to match his hashrate then he would effectively been mining for free for a few days.

So I would suggest either setting up his own node, mining on a smaller node or setting his own share difficulty as you mentioned since his hashrate is so small compared to what the total hashrate is on my node.