[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[trouserless]

Variance? He only mines for 1 day (though at a high hash rate) so it might take longer for the numbers to converge.

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).

In any event, when I posted earlier, I had just restarted p2pool and bitcoind and a few hours later I've got this:

Code:

2012-03-07 20:02:50.438056  Local: 3933MH/s in last 10.0 minutes Local dead on arrival: ~3.0% (1-5%) Expected time to share: 10.3 minutes
2012-03-07 20:02:50.438102  Shares: 71 (5 orphan, 4 dead) Stale rate: ~12.7% (6-23%) Efficiency: ~99.9% (88-107%) Current payout: 0.5926 BTC
2012-03-07 20:02:50.438151  Pool: 265GH/s Stale rate: 12.6% Expected time to block: 6.7 hours

It's reporting the pool rate at 12.6% which is higher than typical, no?  Slightly higher orphan and dead rate than I normally see.

[1714216419]

1714216419

[1714216419]

1714216419

[1714216419]

1714216419

[1714216419]

1714216419

[1714216419]

1714216419

[1714216419]

1714216419

[wachtwoord]

Okay if this is the case you can ignore my previous posts. I think your still rate is indeed higher than average but I am not sure about this even and also don't know how3 to help resolve it.

 

[dub0matic]

I was thinking it would be cool if p2pool.info listed how much has been donated as subsidies.  Maybe that could be added into the luck calculation, too.

That is a good idea.  Maybe a separate item.

Just thinking about how I would detect these...  I could look for sendmany transactions that have known addresses in them.  Maybe the donation address is enough? 

To incorporate these into the luck numbers is a little more tricky.  Right now luck is not measuring amount of BTC earned (vs expected), but is measuring things based on hashes.  I'd have to change it to be based on BTC or I'd have to translate subsidies into "hash equivalents".  I'll think about it more after I look at finding a way to identify subsidy payments in the first place.

Yes please separate it because I have been mining since 30th of January with 252Mhz and still have not received any donation. I might just be really unlucky, but in my mind I've written off the donation aspect in my reasoning to move to/stay at p2pool. So I'd like the data in isolation

that stinks bud. i started at the beginning of march and received a donation the first day

[wachtwoord]

It is because of my low hashing power. If you have a sufficiently high hashing frequency you will get a portion of every donation. For loower frequencies it is supposed to be a chance function. Forrest showed me in this thread. So either I'm unlucky or the function is broken.

Here is the post

Okay, then how come I didn't receive any? (see previous link for the address I use to mine)

Do you see your address in the output of:  http://forre.st:9332/patron_sendmany?total=1

How about in the output of: http://forre.st:9332/patron_sendmany?total=10000

If you address is in the second one but not the first one, then I believe that is because of the small miner lottery. 

In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.

"Small Miner" depends on the size of the donation.  If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket.  If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.

P.S.  The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'.  For example, here is a 1 BTC donation with a 0.001 cutoff instead:

http://forre.st:9332/patron_sendmany?total=1/0.001

But the function no longer seems to work

[kjj]

It is because of my low hashing power. If you have a sufficiently high hashing frequency you will get a portion of every donation. For loower frequencies it is supposed to be a chance function. Forrest showed me in this thread. So either I'm unlucky or the function is broken.

Here is the post

Okay, then how come I didn't receive any? (see previous link for the address I use to mine)

Do you see your address in the output of:  http://forre.st:9332/patron_sendmany?total=1

How about in the output of: http://forre.st:9332/patron_sendmany?total=10000

If you address is in the second one but not the first one, then I believe that is because of the small miner lottery. 

In order to prevent lots of tiny payments, the donation code takes all the people who would have received only a very small donation payment, adds up all those payments, and awards the entire amount to one of those small miners randomly.

"Small Miner" depends on the size of the donation.  If someone is donating 1 BTC at a time and the pool hashrate is 200GH/s, and the small payment cutoff is 0.01, then you have to have approx 2GH/s to not fall into the "small miner" bucket.  If someone donates 10 BTC in one fell swoop, then you only need to have 200 MH/s in order to be above the 0.01 payment cutoff.

P.S.  The default cutoff is 0.01, but people doing donation can choose a different one by adding it to the URL with a '/'.  For example, here is a 1 BTC donation with a 0.001 cutoff instead:

http://forre.st:9332/patron_sendmany?total=1/0.001

But the function no longer seems to work

The URL format was changed.  It was in this thread a couple of times, but tends to get lost in the flow.

Try this:  http://forre.st:9332/patron_sendmany/1/0.001

[forrestv]

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_Questions

EDIT: 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).

[DeathAndTaxes]

I had a question about staleness and efficiency.  I've been mining here a while with about 3.8GH/s and I have noticed that when I start my miners on a fresh instance of p2pool/bitcoind, the stale rate starts at 0% and will climb as high as 20% over the course of a day...additionally the efficiency number will start at 112% or so and trail down to the low 90's sometimes over the same timeframe.  From what I have read here, 10% is the stale target for my instance and the p2pool as well (though it's a bit higher for some reason today) and around 100% efficiency is the target where my instance should hover as well (which might explain my 20% drop in BTC payout vs. traditional pool better than variance).

I'm using the git pull on the 5th or 6th for p2pool and 0.6rc2 for bitcoind on linux.  BAMT 0.5 with cgminer 2.2.7.  I've got threads set to 1 on all miners and intensity seems to run well at 7.

Anything I'm overlooking?

Not sure why your stales are so high.  First thing it always starts at 0% that is pretty much meaningless.  It spiking to 112% in a short period of time is equally meaningless.  When you have a small number of shares the "luck" of a single stale can affect that stat by a lot.  Say hypothetically you have 10 shares w/ 1 stale (10% stale or ~100% efficiency)  The 11th share is coming in.  If it is stale your efficiency will drop to 91% if it is valid then your efficiency will rise to 102%.  What matters if the value after some time (say 12 to 24 hours @ 3 GH/s).   Once you have hundreds of shares the value of each one is less material and the number will stabilize.

Yes if you have <90% efficiency you will be getting paid <90% of expected value.  You want efficiency at 100% or very close. 

A couple of ideas:
1) Use latest version of cgminer.  2.2.7 may be fine but some versions are less p2pool friendly.
2) Are your stales mostly dead or orphaned?  Some dead is unavoidable (similar to any other pool) but a high dead may indicate you are pushing the cards too hard and causing invalid hashes.
3) Make sure your system running bitcoind & p2pool isn't overloaded.  Preferably this would be a non-mining system which is mostly idle.  bitcoind & p2pool use some memory and their operations are very latency sensitive.  If they are slow to issue LP you are going to have excessive stales.
4) Make sure p2pool and bitcoind have a high number of connections (this means port forwarding)
5) Make sure your internet connection is solid w/ low latency and good uptime.

As a test try using public p2pool node and see if your stale rates improve.  If it does then it is something in your internet, LAN, p2pool machine which is being inefficient.  If it doesn't improve then the issue lies with the miner.

[DeathAndTaxes]

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 and bitcoin need to be responsive.  As in sub second latency.   If they aren't you will never get good stales.  Remember they work together to form the "getwork engine".  If they are non-responsive then your miners are working on old worthless crap.

You aren't trying to run p2pool & bitcoind on a mining rig off a USB drive running BAMT are you?  That is a recipe for disaster.

If you are having to kill the processes then something is horribly wrong.   It would be no different than mining on a conventional pool where the pool periodically goes unresponsive and the pool admin has to manually kill the back end and restart it.  Do you think your stale rate will be low at that conventional pool?

[chunglam]

Another block by me, 6 blocks in 3 weeks . May be I should start solo mining . Hey Forrestv, I suggest to increase the block founder reward to 1% or at least more than current 0.5%.

2012-03-07 22:36:47.174757 GOT BLOCK FROM MINER! Passing to bitcoind! http://blockexplorer.com/block/00000000000004965dc029339e48d8c5c1c44e2d5b47fd24705809a13634a2f9

[kano]

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?

[forrestv]

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.

[forrestv]

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.

[stevegee58]

I started getting a bunch of twisted errors today from the p2pool client.  I have the latest p2pool, cgminer and bitcoind.
Everything has been running fine for a week and I just noticed this today.

It seems like the bitcoin client itself is unhappy.  I'm using bitcoin 0.6.0rc2 which is the latest AFAIK.  It reports the error "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."

[twmz]

Just thinking about how I would detect these...  I could look for sendmany transactions that have known addresses in them.  Maybe the donation address is enough? 

The donation address appears not to be included in subsidy payments.  So I don't have a consistent way to identify subsidy payments unless someone can provide me one or more addresses that have consistently been mining with a reasonably high hashrate (and therefore has received every subsidy sent in the past) and will continue to be consistently mining with a high hashrate (and will therefore receive every subsidy sent in the future).

I can identify the subsidy payments that I have received, but I know that some payments happened before I switched to p2pool.  And my hashrate is just above the cutoff where if the pool grows much more, I may not receive every payment in the future (because my share would be below 0.01 of the total payment).

The only other thing I can do is maintain a list by hand.  It could still appear on the website, but someone would have to tell me every time a subsidy was sent and I'd have to manually add it to the list.

So...

[gmaxwell]

It seems like the bitcoin client itself is unhappy.  I'm using bitcoin 0.6.0rc2 which is the latest AFAIK.  It reports the error "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."

Based on your comments I'm quite confident that you're actually running 0.6.0rc1. What you are seeing is exactly symptomatic of rc1. You can get rc2 from http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/   if you really did install rc2, are you sure you restarted after doing so?

[stevegee58]

It seems like the bitcoin client itself is unhappy.  I'm using bitcoin 0.6.0rc2 which is the latest AFAIK.  It reports the error "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."

Based on your comments I'm quite confident that you're actually running 0.6.0rc1. What you are seeing is exactly symptomatic of rc1. You can get rc2 from http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/   if you really did install rc2, are you sure you restarted after doing so?

I went to that URL and ran the windows installer .exe and it turns out it didn't overwrite the previous version's executables for some reason.  So I downloaded the corresponding zip file and extracted that, pointed my shortcuts to it and now it's fine.  Weird.

I'm sure I did this upgrade a while back but clearly there's some kind of installer problem with the rc2 windows installer.

[cabin]

Ahh.. this happened to me too.. I thought rc1 had corrupted my database.. but I guess it just never updated. The installer is definitely broken.

It seems like the bitcoin client itself is unhappy.  I'm using bitcoin 0.6.0rc2 which is the latest AFAIK.  It reports the error "WARNING: Displayed transactions may not be correct!  You may need to upgrade, or other nodes may need to upgrade."

Based on your comments I'm quite confident that you're actually running 0.6.0rc1. What you are seeing is exactly symptomatic of rc1. You can get rc2 from http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/   if you really did install rc2, are you sure you restarted after doing so?

I went to that URL and ran the windows installer .exe and it turns out it didn't overwrite the previous version's executables for some reason.  So I downloaded the corresponding zip file and extracted that, pointed my shortcuts to it and now it's fine.  Weird.

I'm sure I did this upgrade a while back but clearly there's some kind of installer problem with the rc2 windows installer.

[trouserless]

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_Questions

EDIT: 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).

I think I know what's going on here.  The "server" I'm running bitcoind on is an older AMD Geode running at 500MHz at a whopping 996 bogomips and 1GB of memory.  I thought that would be enough, but it appears it's not.  I just checked on the p2pool server (a miner doing double duty) and saw in the logs:

2012-03-03 01:27:15.510957 > Failure: twisted.internet.defer.TimeoutError: Getting http://192.168.1.105:8332/ took longer than 5 seconds.

so how pervasive is this timeout?

user@btc2:~$ grep "took longer" p2pool/data/bitcoin/log |wc
   9067  108804 1251239
user@btc2:~$

over 9K since last Saturday, clearly that's sub-optimal, so I need to find a different system to host bitcoind.

[stevegee58]

Ahh.. this happened to me too.. I thought rc1 had corrupted my database.. but I guess it just never updated. The installer is definitely broken.

Is there a thread to report this on?  My guess is we're not the only ones having this problem.

A side note: you can still use rc1 but you have to put a speshul switch on it to work.  I found this in this thread:
https://bitcointalk.org/index.php?topic=63165.msg789043#msg789043

Apparently the only difference between rc1 and rc2 is the internal date where it stops working and starts complaining to upgrade due to the BIP16 switchover.  The "-paytoscripthashtime=1333238400" switch delays it until 20120401.

[ChanceCoats123]

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_Questions

EDIT: 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).

I think I know what's going on here.  The "server" I'm running bitcoind on is an older AMD Geode running at 500MHz at a whopping 996 bogomips and 1GB of memory.  I thought that would be enough, but it appears it's not.  I just checked on the p2pool server (a miner doing double duty) and saw in the logs:

2012-03-03 01:27:15.510957 > Failure: twisted.internet.defer.TimeoutError: Getting http://192.168.1.105:8332/ took longer than 5 seconds.

so how pervasive is this timeout?

user@btc2:~$ grep "took longer" p2pool/data/bitcoin/log |wc
   9067  108804 1251239
user@btc2:~$

over 9K since last Saturday, clearly that's sub-optimal, so I need to find a different system to host bitcoind.

It's over nine-thousand!!!

With that out of the way, I got my mining rig updated to 0.6.0 rc2. To anyone having issues with the installer, the fix is simple, use the .zip. I like to personally overwrite files anyway. Just about anything can go wrong when the installer overwrites (and that is painfully obvious in this case).