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.
Topic: Finding p2pool networks.py values for new altcoins - page 3. (Read 38104 times)
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...
Code:
VTCPayoutAddress+0.001465/0.55
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?
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).
Quote
I can tell tomorrow, if this makes things better or worse...
Did work perfectly for me during the last 12 hours, by the way
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...
Code:
VTCPayoutAddress+0.001465/0.55
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?
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.
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
Code:
VTCPayoutAddress+0.001465/0.55
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.
SPREAD=
600/[block time]=x
x*3=spread
Not saying that it is right but it's what I use.
Code:
bitcoin SPREAD=3 block every 600 seconds Baseline
litecoin SPREAD=12 block every 150 seconds 600/150=4 4x3=12
bbqcoin SPREAD=30 block every 60 seconds 600/60=10 10x3=30
casinocoin SPREAD=60 block every 30 seconds 600/30=20 20x3=60
digitalcoin SPREAD=90 block every 20 seconds 600/20=30 30x3=90 (old spec)
digitalcoin SPREAD=45 block every 40 seconds 600/40=15 15x3=45 (new spec)
worldcoin SPREAD=120 block every 15 seconds 600/15=40 40x3=120 (old spec)
worldcoin SPREAD=60 block every 30 seconds 600/30=20 20x3=60 (new spec)
globalcoin SPREAD=45 block every 40 seconds 600/40=15 15x3=45
dogecoin SPREAD=30 block every 60 seconds 600/60=10 10x3=30
potcoin SPREAD=45 block every 40 seconds 600/40=15 15x3=45
craftcoin SPREAD=6 block every 300 seconds 600/300=2 2x3=6 (old spec)
craftcoin SPREAD=30 block every 60 seconds 600/60=10 10x3=30 (new spec)
SUBSIDY_FUNC = *
pulled from ./src/main.cpp (search for "nSubsidy")
total number of minable coins.
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.
I try to stay on top of the coins I use in my git.
Developers of new alt-coins should also release the right p2pool config immediately when a coin is launched.
This should become a standard practice, so that every p2pool node uses the exact same configuration creating one homogeneous mega pool. I've seen multiple p2pools for the same coin because multiple persons create different configurations. P2pool is pretty useless if the nodes for the same coin do not all act as one.
I like p2pool a lot but I still fail to find correct configurations for new alt-coins.
This should become a standard practice, so that every p2pool node uses the exact same configuration creating one homogeneous mega pool. I've seen multiple p2pools for the same coin because multiple persons create different configurations. P2pool is pretty useless if the nodes for the same coin do not all act as one.
I like p2pool a lot but I still fail to find correct configurations for new alt-coins.
Yes I agree completely! How can we enforce this?
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.
Yeah, only if people would submit a merge request. That would be ideal.
I will probably start a new fork especially for that.
Developers of new alt-coins should also release the right p2pool config immediately when a coin is launched.
This should become a standard practice, so that every p2pool node uses the exact same configuration creating one homogeneous mega pool. I've seen multiple p2pools for the same coin because multiple persons create different configurations. P2pool is pretty useless if the nodes for the same coin do not all act as one.
I like p2pool a lot but I still fail to find correct configurations for new alt-coins.
This should become a standard practice, so that every p2pool node uses the exact same configuration creating one homogeneous mega pool. I've seen multiple p2pools for the same coin because multiple persons create different configurations. P2pool is pretty useless if the nodes for the same coin do not all act as one.
I like p2pool a lot but I still fail to find correct configurations for new alt-coins.
Yes I agree completely! How can we enforce this?
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.
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.
...
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.
...
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.
You can find the P2P_PORT in the coin's source code in the protocol.h file, it's the 2nd value after GetDefaultPort.
You can find RPC_PORT in bitcoinrpc.cpp file, look for GetArg("-rpcport", xxxx), where xxxx is the port.
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.
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.
Quote
P2P_PORT =
pulled from ./src/init.cpp
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.pulled from ./src/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.
Quote
RPC_PORT =
pulled from src/init.cpp (search for "-rpcport")
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.
Quote
DUST_THRESHOLD = 0.03e8
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=1e8Fewer (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!
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).
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.
Ah ok, right. Two different files with different purposes and exactly the same name.
One really should be coins.py. 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).
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]
Attention: the /bitcoin/networks.py is COIN SPECIFIC
Sample /bitcoin/networks.py:
Code:
=math.Object(
P2P_PREFIX=''.decode('hex'),
P2P_PORT=,
ADDRESS_VERSION=,
RPC_PORT=,
RPC_CHECK=defer.inlineCallbacks(lambda bitcoind: defer.returnValue(
'address' in (yield bitcoind.rpc_help()) and
not (yield bitcoind.rpc_getinfo())['testnet']
)),
SUBSIDY_FUNC=lambda height:* >> (height + 1)//840000,
POW_FUNC=lambda data: pack.IntType(256).unpack(__import__('ltc_scrypt').getPoWHash(data)),
BLOCK_PERIOD=, # s
SYMBOL='',
CONF_FILE_FUNC=lambda: os.path.join(os.path.join(os.environ['APPDATA'], '') if platform.system() == 'Windows' else os.path.expanduser('~/Library/Application Support/ /') if platform.system() == 'Darwin' else os.path.expanduser('~/. '), ' .conf'),
BLOCK_EXPLORER_URL_PREFIX='',
ADDRESS_EXPLORER_URL_PREFIX='',
TX_EXPLORER_URL_PREFIX='',
SANE_TARGET_RANGE=(2**256//1000000000 - 1, 2**256//1000 - 1),
DUMB_SCRYPT_DIFF=2**16,
DUST_THRESHOLD=0.03e8,
),
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 =
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 '
SUBSIDY_FUNC =
note: If there is no "halfing" you should take out the ">> (height + 1)//
BLOCK_PERIOD =
SYMBOL =
Like BTC, LTC, DOGE
CONF_FILE_FUNC = change
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]
Jump to: