Frizz23 and anyone else having problems with apparent forks, upgrade to this and follow the above advice.
What happens to all those shared that have been submitted to a forked pool? I haven't gotten any credit for those - so I assume they are lost. Yes, they're gone now; However, they had some value when you created them. The forked pool could have found a block and paid you a handsome amount, but you just didn't have great luck. (Kind of like solo mining for a while and then giving up.) |
|
|
|
Edit: I should add - that when there's an orphan battle, who do you think will win?
A solo P2Pool bitcoind with 8 connections or BTC Guild's bitcoind with ? connections?
If they post them very closely together the winner is usually the one with the most connections and the fastest internet.
Edit2: and if you look at the 2 block hashes, the BTC Guild one is not the one with the harder difficulty either.
000000000000079f7e918f3fba8f758383e1061c5d4eb8b3742612dedc23c00e P2P
0000000000000c163ce8827e37bb459161e6978dc1ff0c052c53dd7f5858608a BTCG
Unfortunately, P2Pool did have an orphan block. However, P2Pool is not at a disadvantage to other pools. P2Pool not only passes block solutions to the local bitcoind, but also passes them to other P2Pool nodes so that they can spread faster. In theory P2Pool should be better for this reason. I've been working on this a bit, because right now stale shares aren't passed around, and that might have contributed to this being an orphan. Also, keep in mind that whoever made this share had it ultimately declared as an orphan because of P2Pool's bitcoin stale rules (probably along with other shares that they mined), so they are being punished for having a too-high latency. Last, the fact that their block's hash is lower does not make any difference at all. |
|
|
|
What rejection rate are you talking about?
The one displayed in my miners (poclbm) window: [Rej: 91/1050 <8.67%>] with the pool I was using before it was less than 1%. P2Pool's rejections are different from pools. Getting some, about 9%, is normal, and doesn't hurt your payout.
Rej: 9% using p2pool will give me as much as, or more, payout than Rej: 0.3% at that other pool? I don't understand how that could be... but I suppose I will just have to let it run a while and see the actual payout and compare that to what I was getting from the others pools I have tried. If your miner is rejecting many shares at all, you're probably using an incompatible miner. Look at https://en.bitcoin.it/wiki/P2Pool#Miners . Is your FPS really low? You should have it at about 30. |
|
|
|
With a hashrate of around: [423.123 MH/s <~378 MH/s>] how often should I expect to see
an increase in my balance, and by approx. how much? I am trying to gauge how well it
is doing compared with the last pool I was at. How often you get paid has nothing to do with YOUR hashrate. You (and everyone else) gets paid when a block is solved and that is based on p2pool global hashrate & Bitcoin difficulty. Right now p2pool has avg block time of ~5 hours but due to variance it could be 20% of that or 500% of that per block (or more). I see, thanks. Right now it is that > 9% rejection rate that will make me want to go back to the previous pool I was at. That and the merged mining I could do there. What rejection rate are you talking about? P2Pool's rejections are different from pools. Getting some, about 9%, is normal, and doesn't hurt your payout. |
|
|
|
P2Pool release 0.8.6 - tag: 0.8.6 Windows py2exe binary: http://u.forre.st/u/szpnzcpo/p2pool_win32_d222f8d.zipSource tarball: https://github.com/forrestv/p2pool/tarball/0.8.6Changes: * IRC announcer doesn't spam as much * Some possible bugs in sharechain ranking have been fixed, so forks may be prevented * Outgoing connections are constrained to one per /16, making Sybil attacks harder Note: I would recommend switching to Bitcoin 0.6.0 RC 1, which includes the RPC getblock call. The getblock call lets P2Pool keep track of block heights more robustly, and so might protect you from sharechain forks. Download it from https://bitcointalk.org/index.php?topic=63165.0Frizz23 and anyone else having problems with apparent forks, upgrade to this and follow the above advice.
|
|
|
|
|
If you simply run a P2Pool node, miners can connect to it over port 9332 with their username as their bitcoin address and mine to their address. Several people have already done this (p2poolparty being one of them, my node @ p2pool.forre.st being another). Nothing complex and no programming is required.
|
|
|
|
So then to repeat a question I asked someone before (looks like I better go find who that was)
If the share difficulty is say 500 (which means 2759 shares per block) and they are mined by 1000 people, then the block will have 1000 payments in it?
I hope not - killing the block-chain seems like a bad idea no matter how ideologically good it seems.
Yes, though having the hash rate distribution be completely uniform is impossible. Some people will get a lot of the shares, so having one address for every two shares is impossible. In addition, a move to SMPPS with a set minimum payout in the future is possible, though I'm not sure that what we have now will be a problem. |
|
|
|
my logfile is fast growing  how I can cut it? where I can see full run_p2pool.exe options list? P2Pool will automatically trim the log file if it reaches 100MB, so you shouldn't have to worry about the size of it. To see options, just run "run_p2pool.exe --help". forrestv; will you consider adding a command line option that limits the total number of connections? My p2pool instance currently has 47 connections, and this plus bitcoind's connections I fear might be too much for my cheap router. At least this could be the case when other people need to use the connection too for torrent downloads etc.
Okay, will do. The coinbase txn is limited to a certain number of payout (otherwise these p2pool blocks would be ENORMOUS)
So what happens to all the small unpaid amounts?
Since the share-chain only lasts N days ...
The generation transactions pay everyone. The sharechain lasts one day, and there are only a few hundred unique payout addresses which are all paid out. Thanks for that chart. Definitely important for any small miner. I have a lot to learn here but there seems to be no point at all mining in p2pool if you're a small miner. And small miners will figure this out quickly and move back to their favorite pool.
"No point"? Your expected payout is the same as mining on a pool, but there's just more variance. There are lots of solo miners that are somehow happy with getting less than one block per day, so why can't these small miners cope with less than one share? That said, I'm thinking about several methods that would decrease P2Pool's difficulty, such as letting the big miners on P2Pool voluntarily raise their difficulty so that the smaller miners can use a reduced difficulty while maintaining 10 seconds per share. |
|
|
|
I don't think that that will work. It doesn't seem to support the "getmemorypool" RPC call. |
|
|
|
Maybe look in P2Pool's log around those times?
Is any other log rather that one that I at the output on the screen? There's a log file in data/bitcoin/log. Also, P2Pool doesn't use IPv6; The traffic displayed on that graph is tiny anyway. |
|
|
|
I keep getting the following error. It's on Arch Linux. Dependencies should be installed and everything seems to work well. It loads shares and build up connections, but after a few seconds this is what I get. Version 5250df6.
neptop, that's kind of normal if you're downloading the sharechain on a slow computer. The "Watchdog" errors just mean that P2Pool didn't respond for a while, in this case because it was spending time processing shares. This shouldn't happen in normal operation. Another question... can somebody comment why it is such big variance in mining speed?
Is it because of intensity in miner is not on maximum?
Can somebody explain why it is better to set intensity 20% below maximum? ( like -I 8 is better than -I 10 in cgminer)
Seeing some variance is normal. P2Pool estimates your speed from the number of pseudoshares your miner submits, which varies randomly. Lower intensities make your miner work on smaller chunks of work at a time, so they can start on a new one faster when a long poll comes in. However, I don't think that that is your problem because of the bulges in the dead rate... Maybe look in P2Pool's log around those times? |
|
|
|
... Note: I would recommend switching to Bitcoin 0.6.0 RC 1, which includes the RPC getblock call. The getblock call lets P2Pool keep track of block heights more robustly, and so might protect you from sharechain forks. Download it from https://bitcointalk.org/index.php?topic=63165.0LOL they are finally adding it into the bitcoind code - I add my own slightly different version into every release - quite annoying actually  Hopefully they don't send out half processed scriptSigs like some silly person came up with the idea and everyone has used ever since. Meanwhile ... my question 2 pages ago about bad addresses in the share-chain - can they get in there and make the blocks fail? No - fine. Yes - you need to fix it fast. No. Blocks are only rejected if the scriptPubkeys have too many OP_CHECKSIGs, which P2Pool checks for. |
|
|
|
Are we having another split? My p2pool is verifying only half of the total shares in the chain at the moment, and estimated current payout is about half of what it usually is.
I'm running p2pool tag 0.8.5.
The only way to tell whether you're on a split is if the displayed pool hashrate is significantly less than what it actually is, which is currently ~200GH/s. Your estimated payout can decrease if your payout address changes, which can happen automatically if you restart Bitcoin. Thank you for the answer forestv. I'm getting ~200GH/s so I guess I'm still on the main pool. By the way, can you think of a reason why only half of the shares in the chain would be reported as verified? This happened to me only once before and it was during a split, which is why I thought it could be happening again. 2012-02-12 02:59:38.372000 P2Pool: 17350 shares in chain (8969 verified/17354 total) Peers: 30 (0 incoming)
If P2Pool's data directory was removed, it has to redownload the sharechain, and it can only verify half of them then. You have to wait a day for them all to be verified. If another sharechain is coexisting with the main one, your client will download both and might display about a quarter as unverified... But that's not the problem here. |
|
|
|
Are we having another split? My p2pool is verifying only half of the total shares in the chain at the moment, and estimated current payout is about half of what it usually is.
I'm running p2pool tag 0.8.5.
The only way to tell whether you're on a split is if the displayed pool hashrate is significantly less than what it actually is, which is currently ~200GH/s. Your estimated payout can decrease if your payout address changes, which can happen automatically if you restart Bitcoin. |
|
|
|
I see this line under current payouts.. is it anything to be worried about or is it someone just using a weird payout address?
"Unknown. Script: 202986d5879cfd55f909e272989e1bcc3861dbb8c0a8f4ecb4cf904bcecb5f2c90": 0,
I see this at the bottom of the table on this page. I thought it was someone who had specified a bad address with the "-a" option. But that was just a guess. Smart people will help... That output is just a quirk of P2Pool - It creates a fake transaction output that is used to make work unique while giving miners complete control over the coinbase script's contents. It's scheduled to be removed soon, though, by putting the data back into the coinbase script. |
|
|
|
just did a grep -E "BLOCK|SHARE" and... 2012-02-09 17:27:28.024363 GOT SHARE! c fd031bab prev af58e024 age 5.44s
2012-02-09 17:27:28.035106 GOT BLOCK FROM PEER! Passing to bitcoind! fd031bab bitcoin: 6bdb99d5aab93a5cc5b36c427eb07657011f7354e92d81b47b1
I've been on this for a little less than a week at ~2GHs  'GOT BLOCK FROM PEER' means someone else found a block and they are just telling your node about it. 'GOT BLOCK FROM MINER' means you found a block. No, the fact that he got the matching share right before it would indicate that he solved it. P2Pool should have displayed "GOT BLOCK FROM MINER" right before the "GOT SHARE" line.. not sure why he didn't quote that. |
|
|
|
|
Show Posts
