SPREAD

[roy7]

P2Pool on VTC is the first time I started using it. I just discovered ltc's block period is artificially low because of their dust problems. Spread for vtc networks.py should have been 12, not 3, I think to match the way all of the other coins do it (based on BLOCK_PERIOD). An argument could be made for more than 12. But 3 is what causes 1-2 GPU miners to have such huge variance, because the share window is 1/4 the "normal" size.

Changing it now would require a new identifier and forking to a new p2pool network. But might be worth it. Not sure... also this does reduce dust. But it also causes so much confusion by tiny miners.

[donSchoe]

I agree. We should push that and inform the p2pool operators.

I also noticed that flaw.

[roy7]

The problem is that it will make the network incompatible between those who change and those who don't. A new Identifier should be used so the two networks continue to work properly. I don't know we'd notify everyone though. Normally when p2pool has an update it has a way to do version checks and the change only goes live when enough hash power has changed to it. I don't know how to make a networks.py correction in that manner, however.

[erkmos]

I think we should change this too, your changes to vardiff is also a good idea I think

[roy7]

erkmos is referring to a change I'm testing, the diff is at

https://bitcointalk.org/index.php?topic=18313.msg5030281#msg5030281

[donSchoe]

Please someone create a pull request.

Is it this issue btw?
http://www.reddit.com/r/vertcoin/comments/1wynyy/why_p2pool_is_having_troubles_and_a_solution/

[erkmos]

I've added one with a higher spread, vardiff should be a seperate commit once roy finishes testing it.

[roy7]

I replied to the reddit thread to try and help clear up confusion a bit. erkmos did you also change the identification string? Thanks.

[erkmos]

Yes, see: https://github.com/donSchoe/p2pool-vtc/pull/3/files#diff-ca7649ac6618b5e917c8bc62f2610148R133

[roy7]

Looks good. There is only one seed node so we should be sure he will upgrade in sync with the other bigger pools before actually did try to deploy the new settings. I believe data directory should be deleted too so a new sharechain starts from scratch, which means 3 existing share data would be lost to do the upgrade and someone would need to run with persist=false at first to bootstrap it. Maybe the existing share chain data could be retained, I'm not positive on the result of that though. As new shares come in it would push old shares out eventually, and we'd retain current payment data and histories...

[erkmos]

Do you mean p2pool.etyd.org? I run that node so that shouldn't be a problem, but donSchoe's node is a also in the bootstrap list (maybe I managed to link the testnet entry)? I'll add some kind of notice on the scanner about the imminent upgrade. Also, maybe we should decide on a date for upgrade. How does two days from now sound? Too soon?

[naplam]

Hi, I run Crunchpool (about 10% of vtc p2pool). I think we should set a fixed date and time for the change and we should notify all p2pool operators beforehand. 2 days from now seems fine. I'd rather do it before friday because I'll be travelling this weekend

[erkmos]

Let's do thursday at 22.00 GMT then if we're gonna try to synchronize it, I'll start spreading the news I guess.

[mtnksf]

Hi, I run public LTC/DOGE p2pool http://cryptomine.jp and planning to add VTC p2pool.
I want to start with new version of VTC p2pool.
Will you update master repository at thursday at 22.00 GMT?

[erkmos]

I think thats the plan. But meanwhile you can get the new settings from https://github.com/erkmos/p2pool-vtc/blob/spread12/p2pool/networks.py#L132 , the changed lines are 132-134 and 140 just keep in mind that the new network won't be live until 13th feb at 22.00 GMT (no seed nodes are running yet).

[mtnksf]

Thank you. I will start new VTC p2pool node at 13th Feb.

[roy7]

I put a bold notice at the top of both of my nodes with a link to this thread.

[roy7]

We've talked about it a few times on #p2pool-vtc. Should I put in a pull request for my patch to assign miner work based on payment address hash rate instead of node hash rate? It has really made a difference on the node I'm testing it on. Basically this way a miner on a public node will have the same difficulty to get on share chain as if they were running a node themselves. Right now it's much harder for a miner on a large public node than if they ran a personal node.

https://bitcointalk.org/index.php?topic=18313.msg5030281#msg5030281

[erkmos]

So far my testing shows the same positive results, all except one miner on my node has seen pretty much uninterrupted payouts since I implemented the change.

http://p2pool2.etyd.org:9171/static/graphs.html?Day

I guess the Implications of this change is that if everyone gets paid in every block there will be a lot more transactions in each block. But I don't see how it would be worse than every miner on the network mining on their own node (which p2pool was designed for). Maybe your change coupled with our 4x increase of SPREAD will make p2pool acceptable for slower hashers. At least over some limit, currently the ~175khash guy has found nothing on my node in >12 hours, even with the change.

Given what I've seen so far, I can only recommend you push the change, we should try to get both changes in before the update tomorrow!

[donSchoe]

Updated code, pls update your pools on thursday 22:00 gmt.