Topic: P2Pool Detailed Settings for Altcoins - page 3. (Read 12979 times)

Please deeppurple72, let's keep this conversation on github. You made your point and I understand it and I accept it.
Of course you are welcome any time to join and contribute in documenting more in detail the internals of the P2Pool configuration.
If not now in several months, or whenever it will not be an obstacle to your goals/plans.

Like I said, I will share with the community soon.
2nd of all, your code was not rewritten, and not being "sold"
3rd because the new coins have low diff, 0 nodes/ 0 peers is actually an advantage
4th I would like to run the new pools for several months and then share with the
community the knowledge.... I am not attempting to "sell" some custom
modification of p2pool software, so let me make that perfectly clear!

There is a forum on bitcointalk.org about "HOW TO MAKE ALT-COINS WORK WITH P2POOL"
that has alot of good information. I just happened to discover on my own lots of additional information. When I said "bounty", it referred to information, and NOT p2pool software.

Also, you will notice that I did NOT post any wallet addresses, as I did not seriously
expect anyone to actually do that.

Let me run some pools for a few months so I can make a little something first,
then I will glady clue you people in....

Also, you guys were very hard on me when I requested some kind of way to penalize
those cloud-miners, pools running into pools, "excessive hashrates"
calling my request "ludicrous" and such....

and then you wonder why I suddenly don't feel so friendly?

Hmmmm........

Hi CartmanSPC,

first of all thanks for all the work you put in organizing this information about P2Pool. Reading it put me up with most of the knowledge I have of configuring new P2Pools for altcoins.
I guess you read the disappointing answer of deeppurple72 on Github (if not go and check it https://github.com/forrestv/p2pool/issues/157#issuecomment-35691652).

If you don't mind I'd like to help/contribute to the work you have started, and join forces to figure out how to make as many interesting cryptos as possible with p2pool.
And then redistribute the code + the documentation for the good of the community as a whole.

If you think it's too much work or you are not interested I will understand. But then I'll try to carry on on my own and of course give you all the credit you deserve!
Ciao!

To your own miner? /DIFF will control your share target to gets shares on the chain, +DIFF will control your pseudo share target to report work back even if it's lower than share target.

How can I contol what diff p2pool will send to miner?

Thanks for posting this ,I started working on adding our stuff and quickly realised there was more
to it than I thought there would be .. 

PERSIST=True
You need to set it to False to bootstrap the sharechain, but once you've done that and have a bootstrap node up, set it to True
It prevents anyone else from bootstrapping a sharechain

p2pool/networks.py

Unlike p2pool/bitcoin/networks.py some of the values here may be subjective and not clearly defined.
I will add my own personal comments to each setting. Please feel free to add your own or discuss opposing viewpoints.


For reference here is the section of the code for litecoin:


For now here are some of my notes (work in progress):

SHARE_PERIOD
SHARE_PERIOD sets a target time for how often to provide a share. It will regulating the difficulty to try to hit that target time taking into account the setting in TARGET_LOOKBEHIND.
A lower number will have the effect of a lower share difficulty but also result in a larger share chain depending on the value in CHAIN_LENGTH. It may also cause additional orphans in the p2pool share chain as too low a difficulty will mean multiple miners will find shares at the same time. Not necessarily a bad thing as your all working on finding the same block but the winning finder will get the credit for the share.

Comment
I have seen people say a good rule of thumb is setting this to 1/5 of the altcoin block period. Too high a number will provide a higher diff share favoring higher hash rate miners. Too low a number increases resources (traffic, memory, storage) and orphans from competing miners finding the same shares. I believe setting this to 10 for most altcoins with block times of between 0.5 - 2 minutes is a good compromise.


CHAIN_LENGTH
CHAIN_LENGTH is the number of shares p2pool keeps before discarding them. It needs to be larger than or equal to REAL_CHAIN_LENGTH (it is normally equal to). One reason it increase this would be to show more data in the recent blocks found list.

Example: 24*60*60//10 = 1 day of shares. 7*24*60*60//10 = 7 days of shares. [verification needed]

REAL_CHAIN_LENGTH

REAL_CHAIN_LENGTH sets the total number of previously found shares to include in the payout when a block is found. A longer chain provides a larger amount of time to find a share (get paid for work).
It also contributes to how long you need mine to reach your "full" payout amount.

Comment
24*60*60//10 is calculated as follows:
(24*60*60)/10 = 8,640 shares are paid when a block is found.

Take the value in SHARE_PERIOD and multiply by the number of shares to find how many seconds a share is valid for.
For example:

8,640 shares will be paid with a share expected to be found every 10 seconds
8,640 * 10 = 86,400 seconds
86,400 / 60 = 1,440 minutes
1,440 / 60 = 24 hours
24 / 24 = 1 days

I have tried various REAL_CHAIN_LENGTH settings but have settled on 24*60*60//10 for the following reasons:
Allows a 24 hours period of time for finding of a share and for those shares to be valid based on having a share period of 10 seconds.

• Allows smaller miners time to find a share within 24 hours

• Amount of time to full payout increased but so does the time you continue to receive payment after you stop mining

• Takes longer to ramp up to your full payout amount but you continue to get paid for about the same amount of time after you stop mining. With a  CHAIN_LENGTH setting of 24*60*60//10 I would say most miners reach their full payout between 6-8 hours and continue to receive a payout for about the same amount of time after they stop mining (depending on their hashrate and the setting in spread).
  

TARGET_LOOKBEHIND
Determines the number of shares counted for difficulty regulation.
Used to determine share difficulty based on the hash rate of p2pool (not individual nodes).

Comment
Some people set this really low but I recommend it be kept at 200 as it will modify the share diff based on the previous 200 shares rather quickly. I think they believe it will take TARGET_LOOKBEHIND*SHARE_PERIOD='time it takes to adjust' but I feel it actually uses the last 200 shares and adjust based on the average. Setting too low a number does not give it a large enough number of shares to determine the proper value and adjust smoothly.
With large miners coming and going the difficulty adjustment takes too long with 200 shares on smaller p2pool networks. On larger p2pool networks this is not noticeable but I have resulted to setting this to 20 to accommodate large miners coming and going.

SPREAD
SPREAD determines how many blocks (max) to pay if a miner finds at lease one share.
Does not go beyond the CHAIN_LENGTH/REAL_CHAIN_LENGTH setting.

Comment
600/[block time]=x
x*3=spread


It is not a hard limit # of blocks, it is the # times the average work required to solve a block.  In other words, for a SPREAD=3 if the average time to block is 8 hours, then your shares will fall off the payout after 24 hours.  So, if p2pool happens to get lucky and solve 10 blocks in that 24 hour period, your share will be paid for all 10 blocks.



--------------------
To generate unique values for IDENTIFIER and PREFIX create a random string of 19 numbers and convert to Hex.

I use the windows Programmer Calculator to do the conversion (View menu).

Example:
5486237465184378845 = 4C2307E841C11FDD

....more to come!

p2pool/bitcoin/networks.py

This is where the coin specific settings are stored. All the information in this file needs to come from the source code of each coin and be updated if any of that information is changed.

For reference here is the section of the code for litecoin:

litecoin=math.Object(
Change litecoin to match the name of the altcoin.

P2P_PREFIX='fbc0b6db'.decode('hex'),
Replace 'fbc0b6db' with the values from main.cpp at pchMessageStart[4] =
Remove all '0x' and combine the rest.

P2P_PORT=9333,
Replace 9333 by looking in protocol.h and finding the 2nd value after GetDefaultPort
Some coins may have this in chainparams.cpp at nDefaultPort =

ADDRESS_VERSION=48,
Look in base58.h and find the value of PUBKEY_ADDRESS

RPC_PORT=9332,
Look in bitcoinrpc.cpp for GetArg("-rpcport", xxxx), xxxx is the RPC_PORT.
Some coins may have this in chainparams.cpp at  nRPCPort =

RPC_CHECK= ... 'litecoinaddress'
Look in bitcoinrpc.cpp after setaccount <
If the altcoin has a 'space' between altcoin and address make sure you include the 'space'.
You can also find this in rpcdump.cpp after dumpprivkey <

SUBSIDY_FUNC=lambda height: 50*100000000 >> (height + 1)//840000,
SUBSIDY_FUNC=lambda height: 'block reward' * 'satoshies' >> (height + 1)//'height where block halves'.
For 'block reward' look in main.cpp for nSubsidy
For 'height where block halves' look in main.cpp for nSubsidy -> nSubsidy >>= (nHeight /
If a coin does not have a height where the block halves take out >> (height + 1)//'height where block halves'

Comment
Pay particular attention to verifying that you have this correct. Not doing so will result in some blocks being rewarded less than their full value.

SUBSIDY_FUNC is only used in some instances.

I have not seen a solution for coins with a random block reward. For random block reward coins some have suggested that the 'block reward' should be set to a low number as a high number would cause the block to be rejected [try to verify].

To do
Determine the correct SUBSIDY_FUNC for coins that decrease by a percentage (WDC, Digibyte).
Determine the correct SUBSIDY_FUNC for coins that have a random block reward (DOGE, LEAF, FLAP PENG, MEOW, etc).



....more to come. For now here are my dirty notes:

BLOCK_PERIOD=
------------------------------------------
target time between blocks
pulled from src/main.cpp (search for "static const int64 nTargetSpacing")
------------------------------------------

SANE_TARGET_RANGE = (2**256//1000000000 - 1, 2**256//1000 - 1)
No changes for scrypt.
DUMB_SCRYPT_DIFF = 2**16
No changes for scrypt.

DUST_THRESHOLD =
Note about DUST_TRESHOLD: In an effort to reduce the number of very small dust payments hanging around in peoples wallets, it does this by looking at your expected block payment and adjusted the required share difficulty until this is above its DUST_THRESHOLD value.
0.03e8    = 3000000   = 0.03       in satoshis [someone please verify]
1e8       = 100000000 = 0.00000001 in satoshis [someone please verify]
0.001e8   = 100000    = 0.001      in satoshis [someone please verify]

Since it is so hard to find all the information in one location I thought I would start a thread detailing the changes necessary to make most POW altcoins work with p2pool. Thanks go out to all those who have posted this information elsewhere on the forum.

There are two files that will need to be changed:

p2pool/bitcoin/networks.py
p2pool/networks.py

Will break these down in the next two posts. Over time I will update to reflect new information.

Note: When a coin changes it's spec p2pool needs to be changed to match.
Note: All nodes must run the same code. If there are any changes [some exceptions] it is recommended to start a new p2pool share chain by changing IDENTIFIER and PREFIX and deleting the p2pool/data folder.

I maintain a GitHub that I keep updated of the coins I run on xpool.net here:
https://github.com/CartmanSPC/p2pool

Here are some other popular repositories:
https://github.com/narken/p2pool-altcoins
https://github.com/Rav3nPL/p2pool-rav

Please use caution when using some of these repositories as they may not have been updated to reflect changed coin specs.

Link to the original source by forrestv (BTC, LTC, TRC):
https://github.com/forrestv/p2pool