Topic: Finding p2pool networks.py values for new altcoins - page 3. (Read 38034 times)

Hmmm. Even if I try to set /.00001 I can't see it changing anything on my miner's end. Using + of course submits diff 1 pseudo-shares constantly which is a waste of resources.

Looking at all of the New Work messages, they aren't all being set to the same difficulty. On my pool most are set to 0.00244 but one is .000812 and one is .000244. I assume those are the pseduo share difficulties and the tiny ones are the two slowest miners in pool?

Because yes, there is also the "Share difficulty: 1.918" which is going to all but 2 miners. One is me with my /.000001 forcing it down to match share difficulty. That other must be you or someone like you, setting a lower share difficulty with ADDR/ which means you'll actually have reduced variance since the difficulty chosen is still over the minimum.

Is it really 1 share total from all miners combined, or 1 share per minute from each miner individually? The latter would make more sense to me, but I'm thinking of it from a "running a pool-like public node" perspective. p2pool is designed from a "run it as a reduced variance solo mining operation" perspective.

First, I've to admit that I'm not completely sure about how p2pool handle diffs and so on, just my own code reading + try and error.

That said, pool minimum share diff (what you get e.g. with http://vtc.coinpools.de:9171/difficulty) is not what p2pool gives out to your miner as share difficulty (main reason, why the "share difficulty" displayed on the standard web client page is nonsense). p2pool uses a quite complicated algorithm to compute pseudo_share_difficulty (work.py lines 265-) and share_difficulty (data.py lines 111-) specifically for your miner client (see debug.log "New work for worker" entries).

IMHO the main problem with this is, that p2pool tries to dish out share difficulties so that it expects no more than one solved share per minute from all connected clients. So as my VTC node has about 6 MH/s local rate at the moment, the log shows a standard share difficulty of 1.39 given to clients. Minimum share difficulty for the pool is 0.063 on the other hand. So it seems perfectly legit to specify a custom share difficulty of 0.55 for my miner. (If you specify it too low, p2pool seems to use the minimum pool difficulty anyway).


Did work perfectly for me during the last 12 hours, by the way

address/diff won't let you set diff below the minimum share diff for the pool though. It's intended more to raise diff for giant miners than to lower diff, I thought?

You can lower your share difficulty by appending /diff to your p2pool username. That should generate more shares and more regular payouts, but of course you get paid less per share. I'm trying at the moment. I can tell tomorrow, if this makes things better or worse...

Sadly when we did the first vertcoin nodes, we used spread=3 because we just copied litecoin. It really should have been 12-15... would avoid so much confusion for small miners right now. Doh.

For SPREAD I use the following formula:

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


Not saying that it is right but it's what I use.

I believe this is incorrect. I think the correct way is:

for litecoin:
SUBSIDY_FUNC=lambda height: 50*100000000 >> (height + 1)//840000,
SUBSIDY_FUNC=lambda height: 'block reward' * 'satoshies' >> (height + 1)//'height where block halves'.

If there is no "halfing" you take out the >> (height + 1)//'height where block halves'

//840000 is the number from main.cpp in nSubsidy -> nSubsidy >>= (nHeight /

As an example...I believe Ravs git has old specs on some of the coins.

Well, imo that is the responsibly of the coin developer(s). They should submit a merge request then.

One of the problems is that coins occasionally change specs (DGC, WDC, CRCx2 and soon CSC...of the ones I track) and p2pool has to be updated to those new coin specs. It is a very hard job to keep up with everything

I try to stay on top of the coins I use in my git.

Yeah, only if people would submit a merge request. That would be ideal.
I will probably start a new fork especially for that.

I think
https://github.com/Rav3nPL/p2pool-rav.git
has the most complete network.py files for most altcoins. So if you want to add a new coin, probably the best way would be to clone that and do a merge request afterwards. That way there won't be 1001 different versions of p2pool on github, each of them working for exactly one altcoin

Just my 2 cent.

... and thanks a lot @TVB for the hard facts.

I agree, although forrestv really should add it to the p2pool wiki or p2pool.info website
And you are right. 'pulling' the actual configured values from the source is better. Thanks for that!

I think we can now focus on the p2pool specific networks.py values..

Good stuff tvb.

I have considered starting a new thread outlining the values with the OP being updated as needed but will start by making a few comments on yours.

Pulling from that location IMO is not a good idea. Better to pull from the actual code "use" than the notes field in init.cpp.
You can find the P2P_PORT in the coin's source code in the protocol.h file, it's the 2nd value after GetDefaultPort.

Again, pulling from that location IMO is not a good idea. Better to pull from the actual code "use" than the notes field in init.cpp.
You can find RPC_PORT in bitcoinrpc.cpp file, look for GetArg("-rpcport", xxxx), where xxxx is the port.

I understand why they want to do this for Litecoin and Bitcoin but for most alts I feel this setting is too high (or low depending on how you look at it). I think most smaller miners (which is what were really addressing here) would appreciate more consistent payments in smaller increments rather than fewer larger payments. I use DUST_THRESHOLD=1e8

Fewer (but larger) payments (I feel) puts off miners. Yes, it does increase the number of transactions in their wallet and may cost them more in fees when they try to use them but implementing coin control from newer litecoin releases can help there. They can also split up their transactions or wait for sufficient coin age.

Ok, those are my inputs.

+1 for tvb!

Tnx for sharing this tvb!

Ah ok, right. Two different files with different purposes and exactly the same name. One really should be coins.py.

I will soon follow up with details about the /networks.py file which is not coin specific but p2pool specific and thus different from /bitcoin/networks.py!
/networks.py contains the SPREAD value etc.

Fantastic post TVB. Only item you didn't list was SPREAD which I believe is the # of blocks worth of work to pay out, ie the PPLNS window size (N being SPREAD # of blocks of work).

So, I had a little chat with forrestv! Here is some information on how to find the correct settings for the /bitcoin/networks.py file.

Attention: the /bitcoin/networks.py is COIN SPECIFIC

Sample /bitcoin/networks.py:


Detailed explanation

P2P_PREFIX =
pulled from ./src/main.ccp (search for "unsigned char pchMessageStart" and use the value between { } (remove all 0x))

P2P_PORT =
pulled from ./src/protocol.h (search for "GetDefaultPort", 2nd value will be the port value.)

ADDRESS_VERSION =
pulled from ./src/base58.h (search for "PUBKEY_ADDRESS")

RPC_PORT =
pulled from ./src/bitcoinrpc.cpp (search for 'GetArg("-rpcport", xxxx)' where xxxx is the value of the port.

RPC_CHECK change e.g. 'litecoinaddress' to 'address'

SUBSIDY_FUNC = * >> (height + 1)//
pulled from ./src/main.cpp (search for "nSubsidy")
pulled from ./src/main.cpp (search for "nSubsidy >>= (nHeight")

note: If there is no "halfing" you should take out the ">> (height + 1)//"

BLOCK_PERIOD =
pulled from ./src/main.cpp (search for "static const int64 nTargetSpacing")

SYMBOL =
Like BTC, LTC, DOGE

CONF_FILE_FUNC = change , , and

BLOCK_EXPLORER_URL_PREFIX =

ADDRESS_EXPLORER_URL_PREFIX =

TX_EXPLORER_URL_PREFIX =

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 = 0.03e8
No changes for scrypt.

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 (current 0.1000).

Transaction fees in Litecoin have been designed to protect the network from a problem known as transaction spam (dust transactions). If someone was to setup a loop between two wallets, sending back and forth small amounts, they would grow the block chain. Fees prevent this as it becomes too expensive to do this.[/size]