So who were those coins supposed to go to?
It's the first share of the sharechain that was supposed to be paid out, which is supposed to be partially counted. It's incorrectly directed to a nonsense address, and so it takes from whoever had the last share in the payout window... translating to everyone in a small way, in the long run. |
|
|
|
This is a bug in P2Pool. I had been assuming that this was someone mining to that script just for fun, since previous versions of the P2Pool protocol gave you the freedom to choose your payout script. Since then, the rules have tightened, and this should have been impossible. P2Pool computes payouts using a PPLNS scheme, which entails counting the last share only partially, which requires a special case. The special case was broken - The fault was using Python's dict(script=...) syntax instead of {script: ...}. See http://pastebin.com/0RfRWZ21Fixing this will break compatibility with current versions of P2Pool, so it will take some time. Thanks for pointing this out. |
|
|
|
.. and after the last restart there's no more block not found errors but a new one...
Normal, just an old peer. The next release will hide this message unless you're in debug mode.. |
|
|
|
No, everything local stayed the same. Orphaned/dead stayed around 5% overall, still cranking out shares about every 25 minutes, nothing here reporting errors anywhere. Just a steady decrease in hashrate shown at p2pool.info and a steady decline in payout values. It's like over 50% of my hashrate/shares are leaving my end, but aren't making it into the chain.
I just did a fresh install of Bitcoin 0.6.0r2 and p2pool on the server and re-downloaded the chains on both of them, going to give it until tomorrow morning to see if that fixed it, if not, i have to pull out back to a pool until the problem is located.
Can you run P2Pool in debug mode (--debug) and give me the logs in the morning? If you're already gone, the logs would be helpful even without --debug. |
|
|
|
Well, I hate to do it, but I just pulled my 2GH/s from P2Pool. Something is very seriously wrong. I have been keeping it up to date, so don't tell me it's me version of p2pool or bitcoin, it's not. Over the last 4 days I have watched my payout per block drop from around 0.4 to 0.15 on the last one, and p2pool.info is showing 950MH/s. I will come back, but after what ever the hell is broken is fixed.
Were you getting more orphaned or dead shares, or was the number of shares that you got decreasing? |
|
|
|
Since P2Pool is Peer to Peer, if say half the miners have updated clients, and half are using older clients. I assume that the client who ultimately finds the block is the one that submits it to the network and handles validation of transactions? If so, 50% of the time would we be vulnerable to this flaw with BIP16?
In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?
And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).
All P2Pool users will definitely need to upgrade bitcoind before April 1st because of this issue. The question is of how to prevent people from not upgrading, which can be done by changing the rules of the P2Pool protocol. This could be as simple as a new version of P2Pool that checks bitcoind's version and refuses to work with older versions, combined with a protocol change on April 1st that requires miners to use the new client. Of course, this is vulnerable to people patching out the version check, but P2Pool (along with all other pools) is already vulnerable to malicious block invalidating attacks, so that's not a problem. |
|
|
|
P2Pool's hash rate has dropped lower than it has been in weeks; This may be due to people using Bitcoin 6.0 RC 1 and needing to upgrade to RC 2 due to changes in the P2SH taking-effect date. Please upgrade to RC 2 at https://bitcointalk.org/index.php?topic=63165.0 . If you haven't upgraded, all of your P2Pool shares will be orphaned and you'll see "WARNING: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." in bitcoind's logs or the GUI. |
|
|
|
Anyone know where it is documented what the structure and content of a share is in the share chain? (i.e. technical details of the first paragraph of the wiki) The Wiki https://en.bitcoin.it/wiki/P2Pool isn't very good for technical details (and not up to date - e.g. Donation section is still wrong and it still tries to convince people to be happy with stales) Anyone know if there are any technical documents around about p2pool? There aren't any technical documents, but the share explorer ( http://forre.st:9332/web/explorer) shows the complete content of shares and https://github.com/forrestv/p2pool/blob/master/p2pool/data.py#L29 has the structure descriptions. I updated the donation URLs (thanks for pointing that out), but I don't see what you mean about it trying to convince people to be happy with stales... It explains why you'll get more stales than other pools and gives lots of advice for reducing them. |
|
|
|
Hello Wachtwoord, I was using the one day window as an example, I've been observing this for over a week now, restarting p2pool and sometimes bitcoind when it zombies out. I should have mentioned that bit before, I've got bitcoind 0.6rc2 running on a separate machine where it has enough ram and disk yet a slower processor. I have observed p2pool reporting that bitcoind is not responding for some number of minutes and I have to kill -9 bitcoind and restart. This happens some of the time and often self-corrects (i.e. p2pool eventually reconnects with bitcoind).
P2Pool's wiki page has some suggestions for increasing your efficiency: https://en.bitcoin.it/wiki/P2Pool#Frequently_Asked_QuestionsEDIT: Any idea what's going wrong with bitcoind? If bitcoind is dead and you continue to mine, you'll get orphans because your shares aren't up-to-date (any block solutions would be invalid). |
|
|
|
does p2pool daemon show anything in output when it is using higher share difficulty. I tired /1000 and it doesn't seem to have any effect.
I bumped it up to somewhere around 0.024-ish in my Litecoin p2pool instance, and the new value was reflected in the "share difficulty" lines of p2pool's output. The expected time-to-share doesn't seem to have (yet?) updated, though. It won't. You could have multiple miners connected so the only sane thing to do is display the estimates for the default options. |
|
|
|
I can get diablo running, but it just sits at 0.0Mh/s, even though the P2Pool app seems to be working fine.
It sounds like you might not have the port set .. are you running DiabloMiner with "-r 9332"? If you are, can you pastebin the command that you're running and its output? Check if P2Pool has any error messages and run DiaboMiner with the debug flag too (I think it's just -d). |
|
|
|
|
The transition ~40 hours ago went better than expected. Thanks to all for upgrading.
Now that we're using the new implementation, miners can volunteer to raise their share difficulty by adding something like "/1300" to the end of their miners' usernames. The 1300 is the difficulty of your own shares, and can be changed but must be higher than P2Pool's difficulty (currently 650) to have any effect. I urge anyone whose variance is dominated by P2Pool's block finding to try this (which really means anyone who gets more than a few shares per hour). This has the effect of lowering P2Pool's difficulty for the benefit of small miners, which may let P2Pool grow further.
Last, a side note (mainly to DeathAndTaxes): I just pushed a commit that will add another option ("+1") that lets you choose your pseudoshare difficulty, so you can fix it to some value.
|
|
|
|
|
Notice: The protocol switchover happens in 9 hours. If you haven't upgraded to the latest P2Pool, you should do so now. The first post has binaries for 0.9.2.
A few errors ending like this are expected 1 hour after the switch time, since there will inevitably be a few nodes that haven't upgraded:
2012-02-26 02:31:41.256425 > raise ValueError('old share an hour after switch time')
2012-02-26 02:31:41.256481 > exceptions.ValueError: old share an hour after switch time
Any node that sends invalid shares is banned from connecting to you for an hour as of P2Pool version 0.9.1. This will minimize the impact of un-upgraded peers by splitting them off from the main P2Pool network.
|
|
|
|
I just updated from Bitcoin 0.6.0 rc1 to rc2. I have no idea what this error could mean: 2012-03-01 19:28:47.838000 Initializing work...
2012-03-01 19:28:47.868000 > Error:
2012-03-01 19:28:47.869000 > Traceback (most recent call last):
...
2012-03-01 19:28:47.874000 > File "D:\forrestv-p2pool-b839ff8\p2pool\main.py", line 171, in <lambda>
2012-03-01 19:28:47.874000 > height_cacher = deferral.DeferredCacher(defer.inlineCallbacks(lambda block_hash: defer.returnValue((yield bitcoind.rpc_getblock('%x' % (block_hash,)))['blockcount'])))
2012-03-01 19:28:47.875000 > exceptions.KeyError: 'blockcount'
With rc1 everything works fine. There was a change in the results of the RPC "getblock" command. See https://github.com/bitcoin/bitcoin/commit/fc4f4c2e9a0f90a2fad9279f755d08b99b27796b . There's been a fix for this in P2Pool git... I'll make a release now. |
|
|
|
wait, it should have longer timeouts for longer rounds, if a round lasts less than 10 seconds the miner will throw away current getwork anyway, so while does it limit RollNTime to 10 seconds?
I don't know (ask forrest), but it does. I just looked at the HTTP header it returns and it says 10 seconds. It's so a miner can roll the work locally so that they only have to do one getwork to get enough work for all their cards. I think CGminer does this when it receives a long poll. |
|
|
|
|
Don't worry; your analysis isn't correct.
You've already admitted that P2Pool as a whole has comparable block-finding ability to other pools, so the only thing you could be arguing for is that P2Pool distributes payouts unfairly. It doesn't, because it uses a fair PPLNS based on the amount of work you have in the sharechain.
If P2Pool really were, by its nature, 9% less efficient than other pools, do you really think it would be at all popular? Do you think people who were okay solo mining would switch?
Merging shares is not required provided that everyone has close stale rates (which isn't actually true, but most people with bad stale rates have something misconfigured).
|
|
|
|
So I'm still mining ok? (I upgraded to latest p2pool)
Yes. I'll push some changes soon that drop unupgraded peers instead of throwing up so many errors. |
|
|
|
|
Show Posts
