I've got this error, need help   I've never seen that error before.. Are you using wallet encryption? If so, it's probably because Bitcoin can't generate any more keys without the passphrase, and you should do as the error says - run bitcoind.exe keypoolrefill. And i think moderator should make an exception for p2pool, make it sticked,
cause it's good for decentraliztion.
It would be nice if they would do that.  However, we can keep it up there by keeping it active.. and once it is one of the top ten pools it will be stickied anyway. |
|
|
|
From Git Commit 66cbd54ce70f7135dedd6e3799f0840394ab9cfb: 1 satoshi is always donated so that a list of p2pool generated blocks can be easily found by looking at the donation address Can you provide the bitcoin-address or blockexplorer link please. for Bitcoin. Here's how the rest can be computed: >>> SCRIPT = '4104ffd03de44a6e11b9917f3a29f9443283d9871c9d743ef30d5eddcd37094b64d1b3d8090496b53256786bf5c82932ec23c3b74d9f05a6f95a8b5529352656664bac'.decode('hex')
>>> from p2pool.bitcoin import data, networks
>>> data.script2_to_human(SCRIPT, networks.BitcoinMainnet)
'Pubkey. Address: 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4'
>>> data.script2_to_human(SCRIPT, networks.NamecoinMainnet)
'Pubkey. Address: NFZScDyN9GRRFchLmuCpyJGRHvXPprfABB'
>>> data.script2_to_human(SCRIPT, networks.LitecoinMainnet)
'Pubkey. Address: LeD2fnnDJYZuyt8zgDsZ2oBGmuVcxGKCLd'
|
|
|
|
Hi forrestv, I use Bitcoin address as my miners' username, but I guess merged-mined namecoins are paid to a address of connected namecoind.
Could I specify a Namecoin address in miners' username too?
No, there is no way to affect the Namecoin payouts. P2Pool is just blindly requesting work from namecoind. What does "No type for share1as" mean?
It means that you're connected to somebody running an outdated client and they're trying to send you old-style shares. I probably should have made this a debugging-mode-only message, because I expected it to appear.. I think I'll do that now |
|
|
|
P2Pool 0.7.2 - tag: release-0.7.2 EDIT: Found a critical bug with sharechain ranking, released 0.7.1EDIT: Found a bug with litecoin mining with Artforz's cpuminer, released 0.7.2Windows binary: http://u.forre.st/u/pugaormc/p2pool_0.7.2_55673c5.zipChanges: * Memory usage decreased by about 40% by only caching the last 1000 block headers instead of all * Startup time greatly decreased due to previous change and better share caching * Peers are judged using a heuristic, so the connection count goes to the maximum in seconds instead of many minutes * Fixed bug in judging which of disjoint sharechains should be mined on * Some efficiency improvements for miners * Fixed "KeyError" bug * Stale and efficiency displays now have a confidence interval:
15:08:47.435707 Pool stales: 12% Own: 11±4% Own efficiency: 101±4%
* All cache files (addrs.dat, shares.*, headers) are now created in data/ subdirectory * addrs.dat no longer uses sqlite, instead using plain text, which should be more robust Everyone should upgrade as soon as possible, as we have several competing sharechains due to that bug! Phoenix-miner support is currently broken, but stock cgminer works very well.
|
|
|
|
Do you need to name them at all? They're rather meaningless… I guess the client shows them though?
The client shows them and the numbers are useful for checking whether everything's working correctly. 22:18:09.886410 Pool: 5279MH/s in 8694 shares (8698/8698 verified) Recent: 24.11% >1272MH/s Shares: 2 (0 orphan, 0 dead) Peers: 1
22:18:09.886509 Median stale proportion: 0.236220472441
22:18:09.886543 Own: 0.0
22:18:09.886571 Own efficiency: 130.93%
(This is only based on the two shares, so it's not accurate. It will converge to around 100%) |
|
|
|
Thanks for explaining. I was initially deterred by this supposedly high stale rate.
Yeah, I've thought about renaming P2Pool-stales to something else, because they can't be compared to normal-pool-stales (and discourage people). I haven't though of a good name, though... Any ideas? |
|
|
|
So stales are high ,righ?
I'm ignorant about p2pool but thinking about trying it out. I'd like to be able to see some stats (at least current p2pool hash rate, graphs over time would be great). Are such stats visible to outsiders anywhere?
I'd also like to know if I should expect more stales and if so, how many more are typical?
P2Pool stales are different from normal stales - they still contribute to the pool's useful hashrate (its ability to solve blocks), but you don't get credit within the payout counting system from them. However, everyone gets about the same stale rate - right now it's 25% - so it's fair, because the would-be-losses are evenly distributed, and so have no effect. The P2Pool client displays an "efficiency" percentage based on your stale proportion relative to everyone else's. Normally, it should be around 100%, which means that you have average stales, but it might be lower if your setup is bad. |
|
|
|
I get longpoll requests every few seconds. Is this normal?
I thought they only happen if a new block was found. Is Longpolling used for a different purpos in p2pool?
This is completely normal. P2Pool creates a chain of shares and needs to start working on new work every time someone makes a new share (which happens every 10 seconds, on average). Tuning your miner by increasing the FPS setting (I use 60 with poclbm) or decreasing the intensity a bit can help it cope better with this type of work. |
|
|
|
i guess i need the merged mining proxy by vinced
and a special fork of bitcoind and namecoind
No, you don't. P2Pool functions as a kind of merged mining proxy. Just point --merged-url at namecoind's RPC interface and set --merged-userpass to NAMECOIND_USERNAME:NAMECOIND_PASSWORD. For example, I run namecoind with -rpcport=10332, so I just use: --merged-url http://127.0.0.1:10332/ --merged-userpass user:password. |
|
|
|
P2Pool 0.6 - ffa37a4 - tag: release-0.6 Windows binary: http://u.forre.st/u/isgvcmlb/p2pool_win32_37975f3.zipChanges: - New, incompatible protocol switchover on Dec 2, 5:39:25 UTC - Upgrading before then is vital!
- Donations are optional and percentage is set by --give-author option
- Sharechain length will be reduced greatly, eventually leading to large decreases in memory usage
- Lots of internal cleanup and a few small bugfixes
- RPC call getmemorypool now a requirement. P2Pool will no longer fallback to generating transaction-less blocks
|
|
|
|
Bitcoin 0.5.0 was released a few days ago, so now the "getmemorypool" RPC command required by P2Pool is available to everyone. As for P2Pool, I've been working on the optional_donations branch, which I just merged into master: https://github.com/forrestv/p2pool/commit/8c05bc836d9f695433e26c3b033b5a32939ca218It's been fairly well tested, but help testing now would be useful. Tomorrow (16 hours from now) I will tag and sign the release and post a Windows binary. It is essential that everyone using P2Pool upgrades in the next three days! On Dec 2 at 5:39:25 UTC, all upgraded P2Pool nodes will switch to a new, incompatible protocol that lets users decide the percentage to donate using a command-line option. In addition, memory requirements will be greatly reduced because the number of shares that P2Pool retains has been reduced from two days to half a day's worth. Thank you for your support! |
|
|
|
Hey everyone! P2Pool has kind of been in stasis - I'm waiting for the next Bitcoin release, which will include getmemorypool, which is necessary to include transactions in mined blocks. I've attempted to build a Windows binary, but had some trouble, and so decided to just wait (then thinking that the next release would be out soon...) Switching the donation to be optional has been a plan for a while, and should be implemented in the next few days. It will likely turn out to be a command-line option for the percentage, defaulting to 0.5%.  Merged mining has been supported in git for a few weeks now, and we've all found a few blocks mining on the Namecoin network. Some recent work has been done by coblee - now Litecoin is supported as a P2Pool network (currently ~100kH/s). In addition, there is a bug (possibly related to merged mining) that halts the daemon and caused a large miner to temporarily pull out. (Sorry for not posting replies, I wasn't getting notifications.) |
|
|
|
the base-58 encoding slightly degrades the effectiveness in some cases, though. With base-58 encoding, it's entirely possible to get 2 byte error in the decoded content with an error in just one unlucky position in the base-58 encoded string.
Individual base58 characters don't map to sections of bits, so any error would change every single byte in the decoded data. Some special error correcting code is need here; I don't think normal ones apply if base58 is used. |
|
|
|
I'm mining with p2pool, running forrestv-p2pool-27ab63b / forrestv-poclbm-5590e7c on radeon 5850 on ubuntu 11.04 64bit. Box is a dedicated miner. Seems there may be some stability problems. Indicated hash rate changes dramatically. With a straight forward:
By default, poclbm looks at shares that have been generated in the last 15 minutes when calculating that estimate of the hashrate. P2Pool has a higher difficulty (currently around 19), so you'll only get a share about every four minutes, but sometimes you might not get one for longer. This leads a lot of variance there. |
|
|
|
|
Sorry for missing this ... The "newbie" handling of the forums is really annoying.
What kind of crash were you getting? There's been lots of development work on p2pool since then. Also, there were several deadlocks in the Bitcoin client that have been fixed in Git and should be released soon.
Shares are only counted in the current time that you're running P2Pool. Also, the pool has been higher than 10GH/s for the last week. What miner were you using? People have gotten the lowest stale results with the modified DiabloMiner on the p2pool thread, so that might be helpful to try.
|
|
|
|
As far as I can tell, the patch to phoenix is a patch against an very out of date version of phoenix (forked from phoenix sometime back in July). "sleep" (the function for delaying) does not appear anywhere in the current version of phoenix or the aldyen fork of phoenix. I see no other indication that there is a delay after a long poll, either. I don't know what version is on bamt, but the latest official version of phoenix appears fine.
I was looking at this last night, and yeah, this is true. Sorry for letting it get so out of date! However, there are some other changes made to phoenix to reduce stales. I'm working on a new fork of phoenix at https://github.com/forrestv/Phoenix-Miner-new , and I'm going to submit some pull requests. |
|
|
|
|
Show Posts
