p2pool\networks.py SPREAD=90, # blocks
IDENTIFIER='7696CFD6441FB537'.decode('hex'),
PREFIX='4C2530B5ED0E1EB5'.decode('hex'),
P2P_PORT=23396,
WORKER_PORT=8810
I can see that the published P2Pool code in post #1 has alternate values for the following :- p2pool/network.py SPREAD=72, # blocks
IDENTIFIER='a5aed03050126d6d'.decode('hex'),
PREFIX='b6c0601991aa19a3'.decode('hex'),
P2P_PORT=25396,
WORKER_PORT=25397,
Would you be able to let us know why you chose those values? At least that way we can all come to a consensus P2Pool. I chose SPREAD=90 since from research on the forum I found that this is suppose to be based on the block target time of the altcoin. 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 digitalcoin SPREAD=90 block every 20 seconds 600/20=30 30x3=90 Please correct me if this is wrong! IDENTIFIER, PREFIX and P2P_PORT are random but have to match from pool to pool to successfully connect. Again, got this from researching on the forum so please let me know if you find something to the contrary. Also, not sure if my values are valid since I just used random 19 digit numbers and converted them to hex. WORKER_PORT is the port miners will connect to. This can be unique for each pool. 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 digitalcoin SPREAD=90 block every 20 seconds 600/20=30 30x3=90 worldcoin SPREAD=120 block every 15 seconds 600/15=40 40x3=120 Added my spread setting for worldcoin. The guy who really knows this stuff is Narken as he has a release for a lot of altcoins: https://bitcointalk.org/index.php?topic=198175 |
|
|
|
sorry i havn't had a chance to connect you your pool yet. i will try to do it later tonight.... for those of you whom are going ot try i suggest making a new pool folder so you don't have to worry about deleting data folder. and for simple upgrade just run the new pool on the same port as your current pool so you wont lose connection for your miners. edit: i updated my source www.github.com/novaspirit/p2poolFunny thing is I almost used xsync as the domain name as I own that for other stuff  What do you think of the SPREAD value? I'm not opposed to changing it. dgc.xpool.net as found 12 blocks so far today. Two appear to be orphans. If SPREAD=30 would reduce that I'm all for it but everything appears to be running so well from both the server and client(miner) side with SPREAD=90. I think SPREAD=30 came from an early post in this tread where someone had a sample network.py setting. It was a copy of the settings for franko as he missed changing a few parts from franko (it said franko in parts). |
|
|
|
He sent me a PM yesterday saying he was going to try connecting our pools today. |
|
|
|
Switching back to SPREAD=30. 90 was a disaster found only two blocks both orphans I think that is just way too short a spread for local pool
Hmmm, 90 seems to be working well for me. Perhaps you need to delete the digitalcoin data directory when you make this change. I have seen "disastrous" results making changes without doing so. |
|
|
|
|
Almost every time I look at the digitalcoin wallet it is stuck re-syncing. Is that a problem? Since I run it 24/7 on a dedicated server it's not easy to know when it's in the re-syncing mode. I have added the nodes listed in the first post but that did not help.
This wallet is used by the pool so if it is causing any delays then that is a concern. Don't actually see that it's causing any problems. Have lost some found blocks to others in the network but don't know if the wallet sync issue is the cause.
Only happening on the DGC wallet.
|
|
|
|
Changed the site menus to optimize space. Looks much better now  |
|
|
|
With the discussion of the p2pools, the one thing that I like a lot is that with pools working together, you can designate one of the other pools as a backup if the current pool you are connected to goes down or has any connection problems. When you move to the backup server, you do not lose any of the past work that your miner(s) have done, you continue as though you were still connected to the first server.
Wow, didn't know that. Since PPLNS can take up to 24 hour to reach your full payout amount that is a powerful feature. |
|
|
|
|
To expand on the example of the one miner at the ltc.xpool.net:9327 node you can lookup his payment address in the charts. Then go to the payout section and search for his address. You will see his expected share of the next payout along with everyone else's in the entire 620 Mh/s pool...kinda neat if you think about it.
When you select a p2pool you will want one that is obviously participating with other p2pool to increase the frequency of payments. Selecting a p2pool comes down to finding the one that is "closest" to your miner. By closest I mean has the lowest latency. Also look for a p2pool that has a low number of orphaned shares. I hear that dead shares don't matter much. You want to be on a p2pool that is reliable (don't go with the hours in node up time section as that resets if the node has to be momentarily restarted..check the graphs for big lapses in data).
I dont want to come off as an authority on any of this stuff though..it is just my understanding from researching the board.
|
|
|
|
one more quick one, concerning all of the talk about networking the P2Pools... would that help cut down on the amount of "requested work restart"s that i'm getting? cause that seems like it would be good? sounds like having them all talk to each other would up everyone's efficiency? would that result in less orphans or rejects, and result in better overall hashing power? would that change how much rewards people are receiving? or if everyone's efficiency gets upgraded at the same time, would it just mean that the network will be more robust but the rewards would still pretty much remain the same?
I found when I changed the setting on the pool to SPREAD=90 it significantly cut down on Stratum request for work restart. Try dgc.xpool.net:8810 to see if that is the case for you there. Connecting the pools will have them using their hash rates collectively for finding blocks. You will get your portion regardless of the p2pool your on when a block is found. More blocks will be found but your portion of the share will be smaller because of the increased number of miners on various p2pools working together. An example can be seen at ltc.xpool.net:9327 Even though there is only one miner at that "node" with 250 Kh/s he will still get a portion of a found block. The entire pool (collective?) is over 620 Mh/s so he is participating with that hashing power even though the local node is only providing 250 Kh/s of it. If it was not connected the miner would rarely if ever be paid with only 250 Kh/s. Since ltc.xpool.net:9327 is participating with the other p2pools he will get paid regularly. Don't know if that makes sense...it is my understanding of it anyhow |
|
|
|
|
WVChYoxtkvnJjfhgQL2Vicix96SBw5ZqFE
|
|
|
|
not to derail what seems like important conversation again with a noob question, but where is the block chain living on my computer after installing the DGC wallet? the folder i extracted seems to be unchanged, but i thought it was was DLing the chain to my PC... tried looking in documents and program data but maybe i missed it?
%appdata% On Windows. We were all there at one point |
|
|
|
p2pool\networks.py SPREAD=90, # blocks
IDENTIFIER='7696CFD6441FB537'.decode('hex'),
PREFIX='4C2530B5ED0E1EB5'.decode('hex'),
P2P_PORT=23396,
WORKER_PORT=8810
I can see that the published P2Pool code in post #1 has alternate values for the following :- p2pool/network.py SPREAD=72, # blocks
IDENTIFIER='a5aed03050126d6d'.decode('hex'),
PREFIX='b6c0601991aa19a3'.decode('hex'),
P2P_PORT=25396,
WORKER_PORT=25397,
Would you be able to let us know why you chose those values? At least that way we can all come to a consensus P2Pool. I chose SPREAD=90 since from research on the forum I found that this is suppose to be based on the block target time of the altcoin. 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 digitalcoin SPREAD=90 block every 20 seconds 600/20=30 30x3=90 Please correct me if this is wrong! IDENTIFIER, PREFIX and P2P_PORT are random but have to match from pool to pool to successfully connect. Again, got this from researching on the forum so please let me know if you find something to the contrary. Also, not sure if my values are valid since I just used random 19 digit numbers and converted them to hex. WORKER_PORT is the port miners will connect to. This can be unique for each pool. |
|
|
|
What does the .0025 do on this?
YOURDGCADDRESS+0.0025
It tells the pool you want to set your miner difficulty at a certain rate. For more info look under the Variable Difficulty section here: https://bitcointalk.org/index.php?topic=217139I would recommend you leave it off but see what works best for you. I have seen conflicting posts on the results. Kh/s Difficulty Result
1 +0.00000116
5 +0.00000582
10 +0.00001164
50 +0.00005821
100 +0.00011641
250 +0.00029103
500 +0.00058207
750 +0.00087310
1000 +0.00116414
1600 +0.001862624 122
|
|
|
|
Have the P2pools started networking with each other?
No! All P2Pools have to be using the same codebase or the P2Pool will be fragmented. Which is what has happened since inception. The codebase in the first post can be used. Maybe a stronger push in that direction would help. This DigitalCoin cryptocurrency has MASSIVE potential ( mainly due to an outstanding developer 'Baritus' ) but we have to all work together. Then WE WILL ALL prosper ;o) ^this The P2Pools should decide on using the same code. I have come up with my own since orphans were so large with the one on the first post. Don't know if it would work any better since no other P2Pool are connected to mine. So far I have has 0 orphans in the last 11 hours. Stats: http://dgc.xpool.net:8810Here is the code I'm using if anyone is interested in connecting: p2pool\networks.py digitalcoin=math.Object(
PARENT=networks.nets['digitalcoin'],
SHARE_PERIOD=30, # seconds target spacing
CHAIN_LENGTH=24*60*60//10, # shares
REAL_CHAIN_LENGTH=24*60*60//10, # shares
TARGET_LOOKBEHIND=200, # shares coinbase maturity
SPREAD=90, # blocks
IDENTIFIER='7696CFD6441FB537'.decode('hex'),
PREFIX='4C2530B5ED0E1EB5'.decode('hex'),
P2P_PORT=23396,
MIN_TARGET=0,
MAX_TARGET=2**256//2**20 - 1,
PERSIST=False,
WORKER_PORT=8810,
BOOTSTRAP_ADDRS='dgc.xpool.net'.split(' '),
ANNOUNCE_CHANNEL='#digitalcoin',
VERSION_CHECK=lambda v: True,
),
p2pool\bitcoin\networks.py digitalcoin=math.Object(
P2P_PREFIX='fbc0b6db'.decode('hex'),
P2P_PORT=7999,
ADDRESS_VERSION=30,
RPC_PORT=7998,
RPC_CHECK=defer.inlineCallbacks(lambda bitcoind: defer.returnValue(
'digitalcoinaddress' in (yield bitcoind.rpc_help()) and
not (yield bitcoind.rpc_getinfo())['testnet']
)),
SUBSIDY_FUNC=lambda height: 1*10000000 >> (height + 1)//1080000,
POW_FUNC=lambda data: pack.IntType(256).unpack(__import__('ltc_scrypt').getPoWHash(data)),
BLOCK_PERIOD=30, # s targetspacing
SYMBOL='DGC',
CONF_FILE_FUNC=lambda: os.path.join(os.path.join(os.environ['APPDATA'], 'digitalcoin') if platform.system() == 'Windows' else os.path.expanduser('~/Library/Application Support/digitalcoin/') if platform.system() == 'Darwin' else os.path.expanduser('~/.digitalcoin'), 'digitalcoin.conf'),
BLOCK_EXPLORER_URL_PREFIX='http://dgc.cryptocoinexplorer.com/block/',
ADDRESS_EXPLORER_URL_PREFIX='http://dgc.cryptocoinexplorer.com/address/',
SANE_TARGET_RANGE=(2**256//100000000 - 1, 2**256//1000 - 1),
DUMB_SCRYPT_DIFF=2**16,
),
p2pool\bitcoin\helper.py if 'lite' in net.NAME or 'feather' in net.NAME or 'chn' in net.NAME or 'franko' in net.NAME or 'digital' in net.NAME:
If you have a current p2pool please don't modify that one and change to this code. Instead, start a new p2pool and use a new WORKER_PORT (does not have to be 8810) otherwise you will get a bunch of orphans from your miners since they are submitting work based on different parameters. Not sure how long that will last. Perhaps until the miner reconnects or accepts the new settings. Either way it's not pretty. All connecting P2Pools must have the same parameters. Path(or something similar): p2pool-11.4\data\digitalcoin Shoot me a message if you try to connect. |
|
|
|
Your having the same problem I was with orphans using hakabanes code. If you like we can connect our two pool together with my code to see if the orphans problem goes away? ...good job though BTW, I found that you have to delete the data/digitalcoin folder between certain code changes. Maybe that was part of your problem. Thanks CartmanSPC , I've added your pool to the boostrap_addr (is dgc.xpool.net right? ) let's see if the orphan rate drop There's more to it than that but lets move this to PM's. |
|
|
|
Your having the same problem I was with orphans using hakabanes code. If you like we can connect our two pool together with my code to see if the orphans problem goes away? ...good job though BTW, I found that you have to delete the data/digitalcoin folder between certain code changes. Maybe that was part of your problem. |
|
|
|
dgc.xpool.net:8810 only has 6Kh/s at the moment (not a typo)  wdc.xpool.net:8820 is over 6.5Mh/s. Don't let those guys have all the fun!  |
|
|
|
|
I had to turn off connecting to other Digitalcoin P2Pools using hakabanes code. Too many orphans.
Check to see that incoming TCP connections to the port your using (9327) are open on the firewall. Will try it now...ok it shows as being down so I can't connect to your pool either.
|
|
|
|
the formula we are going to be using is 2 x (Block Difficulty / Share Difficulty). Very few pools have this implemented correctly, most simply use an arbitrary value like us at the moment. Not using a dynamic calculation means the results are pretty unpredictable. It can take a very long time to reach your full payout if the value is too high or cause too much variance in payouts if the value is too low and the correct value needed changes depending on the Block Difficulty, which changes quite often as you know.
Good work on this! Let us know how it goes. Some miner's don't seem to realize how PPLNS works and pool hop to quickly as a result. This should help. |
|
|
|
It's possible, but also pointless since they don't affect the actual blockchain at all. It's just the wallet loading bar.
Thanks for the explanation! I have noticed this happen a couple of times on the server I use to host the wallet. |
|
|
|
|
Show Posts
