[REWARD] Expertise on share diff code p2pool for CHNcoin (earn BTC or CNC)

[blastbob]

2 BTC or equal CNC. Reward on expertise inputs on p2pool code for CHNCoin (CNC)

Current code in use - https://github.com/chrda/p2pool-chncoin/blob/master/p2pool/networks.py

Code:

SHARE_PERIOD=5, # seconds
CHAIN_LENGTH=12*60*60//10, # shares
REAL_CHAIN_LENGTH=12*60*60//10, # shares
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks

Looking for optimize the p2pool share diff code for CNC.

Only expertise inputs will be considered for reward.

[Narken]

Did anyone respond to your req ?

[blastbob]

no..

[gyverlb]

2 BTC or equal CNC. Reward on expertise inputs on p2pool code for CHNCoin (CNC)

Current code in use - https://github.com/chrda/p2pool-chncoin/blob/master/p2pool/networks.py

Code:

SHARE_PERIOD=5, # seconds
CHAIN_LENGTH=12*60*60//10, # shares
REAL_CHAIN_LENGTH=12*60*60//10, # shares
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks

Looking for optimize the p2pool share diff code for CNC.

Only expertise inputs will be considered for reward.

Make SHARE_PERIOD larger to attract more miners. Only miners with very low latencies can expect a good income with that short a period. Make it at least 10, 15 would be even better (the larger it is, the less miners will have low efficiency but the larger the variance in income might be).
SPREAD is too low for a fast coin like chinacoin (10x faster than Bitcoin and Litecoin). Make it 30 to compensate, this will reduce variance in payouts for miners by a factor of 10 -> good.

Suggested values : SHARE_PERIOD=15, SPREAD=30

If you don't want to see huge problems when upgrading, make sure you both :
- run new pools on different port and not upgrade in place
- publish all your change to a github repository so that other pools might follow you
Additionally you can update the p2p.py file to enforce a new protocol version to make sure older p2pools won't disturb your new network.

Don't play with these values without changing the protocol version once your network is connected to many other nodes: you risk the network to split in very nasty (income losing) ways.

*CHAIN_LENGTH don't matter much on CNC (p2pool has enough relative hashrate that it isn't used in practice to compute miners' income), leave them alone.

TARGET_LOOKBEHIND is fine, it shouldn't need any tuning.

[Narken]

2 BTC or equal CNC. Reward on expertise inputs on p2pool code for CHNCoin (CNC)

Current code in use - https://github.com/chrda/p2pool-chncoin/blob/master/p2pool/networks.py

Code:

SHARE_PERIOD=5, # seconds
CHAIN_LENGTH=12*60*60//10, # shares
REAL_CHAIN_LENGTH=12*60*60//10, # shares
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks

Looking for optimize the p2pool share diff code for CNC.

Only expertise inputs will be considered for reward.

Make SHARE_PERIOD larger to attract more miners. Only miners with very low latencies can expect a good income with that short a period. Make it at least 10, 15 would be even better (the larger it is, the less miners will have low efficiency but the larget the variance in income might be).
SPREAD is too low for a fast coin like chinacoin (10x faster than Bitcoin and Litecoin). Make it 30 to compensate, this will reduce variance in payouts for miners by a factor of 10 -> good.

Suggested values : SHARE_PERIOD=15, SPREAD=30

If you don't want to see huge problems when upgrading, make sure you both :
- run new pools on different port and not upgrade in place
- publish all your change to a github repository so that other pools might follow you
Additionally you can update the p2p.py file to enforce a new protocol version to make sure older p2pools won't disturb your new network.

Don't play with these values without changing the protocol version once your network is connected to many other nodes: you risk the network to split in very nasty (income losing) ways.

*CHAIN_LENGTH don't matter much on CNC (p2pool has enough relative hashrate that it isn't used in practice to compute miners' income), leave them alone.

TARGET_LOOKBEHIND is fine, it shouldn't need any tuning.

Bob, could you please make suggested changes to your git and let me know ;-)

[gyverlb]

Thanks for the tip !

[Narken]

2 BTC or equal CNC. Reward on expertise inputs on p2pool code for CHNCoin (CNC)

Current code in use - https://github.com/chrda/p2pool-chncoin/blob/master/p2pool/networks.py

Code:

SHARE_PERIOD=5, # seconds
CHAIN_LENGTH=12*60*60//10, # shares
REAL_CHAIN_LENGTH=12*60*60//10, # shares
TARGET_LOOKBEHIND=200, # shares
SPREAD=3, # blocks

Looking for optimize the p2pool share diff code for CNC.

Only expertise inputs will be considered for reward.

Make SHARE_PERIOD larger to attract more miners. Only miners with very low latencies can expect a good income with that short a period. Make it at least 10, 15 would be even better (the larger it is, the less miners will have low efficiency but the larger the variance in income might be).
SPREAD is too low for a fast coin like chinacoin (10x faster than Bitcoin and Litecoin). Make it 30 to compensate, this will reduce variance in payouts for miners by a factor of 10 -> good.

Suggested values : SHARE_PERIOD=15, SPREAD=30

If you don't want to see huge problems when upgrading, make sure you both :
- run new pools on different port and not upgrade in place
- publish all your change to a github repository so that other pools might follow you
Additionally you can update the p2p.py file to enforce a new protocol version to make sure older p2pools won't disturb your new network.

Don't play with these values without changing the protocol version once your network is connected to many other nodes: you risk the network to split in very nasty (income losing) ways.

I knew it, that's why we have had so many payout problems

[gyverlb]

Thanks for the tip !

Note that another advantage of making SHARE_PERIOD larger is that it lowers the amount of traffic between nodes and between nodes and the load on them.
It marginally lowers the amount of traffic between miners and nodes (less longpolls or stratum equivalents: the nodes send less data to miners) but it should be negligible.

[Narken]

Thanks for the tip !

Note that another advantage of making SHARE_PERIOD larger is that it lowers the amount of traffic between nodes and between nodes and the load on them.
It marginally lowers the amount of traffic between miners and nodes (less longpolls or stratum equivalents: the nodes send less data to miners) but it should be negligible.

Where in p2p.py in version changes needed to force new protocol version ?

in ?
        self.send_version(
            version=1100,

[gyverlb]

Thanks for the tip !

Note that another advantage of making SHARE_PERIOD larger is that it lowers the amount of traffic between nodes and between nodes and the load on them.
It marginally lowers the amount of traffic between miners and nodes (less longpolls or stratum equivalents: the nodes send less data to miners) but it should be negligible.

Where in p2p.py in version changes needed to force new protocol version ?

in ?
        self.send_version(
            version=1100,

I'll have to check the code to answer this. But I don't think you want to update this at this point. There are 2 reasons :

• You probably have enough control on the nodes on your network to switch to the updated configuration with very few other people being impacted (details below).
• You probably want to be included in the main P2Pool codebase (this means defining a new network instead of overriding litecoin) or fetch updates from it at some point and upgrading the protocol version would make this impractical.

How to handle the switch to a new configuration:

• change the list of seeds to new ones in your git fork
• start new nodes on these seeds with the new code
• announce your change publicly (with a notice that old nodes will be shut down in 24h for example)
• point people wanting to install a P2Pool node connecting to yours to your git tree so that they can make the switch. recommend them to install their node from scratch instead of trying to upgrade in place (which might let them connected to nodes on the old network and would put unnecessary load on their node without impacting yours as they would act like a filter discarding the data from these nodes)

To be included in the main codebase, you should probably try to reach the main developper (forrestv) here or on IRC. There are contributors in the #p2pool IRC channel that might help too.