Topic: p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival] (Read 35481 times)
January 25, 2012, 06:52:49 PM
This is an archived thread of P2Pool discussion.
See the new thread for more recent P2Pool discussion.
January 25, 2012, 05:38:51 PM
I actually kind of like the uncertainty. It is always a nice suprise when suddenly a mined block pops up in the bitcoin client.
Except for today, my miner crashed while I was away and my last shares expired just before finding the two blocks
Except for today, my miner crashed while I was away and my last shares expired just before finding the two blocks
January 25, 2012, 03:18:26 PM
actually thats not quite right. btcserv is a 0% PPS - so you will make the same money on average
But this is way more fun
and i get "mined" in my wallet instead or "received" from the pool's address
But this is way more fun
and i get "mined" in my wallet instead or "received" from the pool's address
January 25, 2012, 02:00:11 PM
that actually means you will get ~0.7 per day on average
and its not the same block, we are always working on the latest block in the chain
EDIT:
and we just got another one solved
http://blockchain.info/block-index/852772
at 200Mhash i got 0.88466231BTC in the last 3 days
actually it was 2 blocks:
http://blockchain.info/block-index/852769
and its not the same block, we are always working on the latest block in the chain
EDIT:
and we just got another one solved
http://blockchain.info/block-index/852772
at 200Mhash i got 0.88466231BTC in the last 3 days
actually it was 2 blocks:
http://blockchain.info/block-index/852769
January 25, 2012, 01:51:09 PM
I am using p2pool now since 6 days. The last 4 days it seems "we" are working on the same block.
The logs says: "... Payout if block: 0.35 BTC ...".
So a measly 0.1 BTC / day. And only, if the block is resolved now(ish).
I think p2pool is not for me. To risky. Or buggy. Or both ...
The logs says: "... Payout if block: 0.35 BTC ...".
So a measly 0.1 BTC / day. And only, if the block is resolved now(ish).
I think p2pool is not for me. To risky. Or buggy. Or both ...
January 25, 2012, 06:47:58 AM
- Run p2pool:
- ...
- Source: python run_p2pool.py USER PASS
(Ubuntu 11.04)
Must run_p2pool.py be run with its distributed directory the current directory -- does it depend on other files in the distribution? Or can run_p2pool.py be copied to somewhere else?
.You don't have to cd to the directory in order to run it. Just execute run_p2pool.py from anywhere.
January 25, 2012, 04:35:48 AM
Strange things going on here:
The windows exe (p2pool_0.8.1_c7feb00.zip) works as expected, about one share per hour or so.
Today I tried installing Python 2.7 and using the source (forrestv-p2pool-release-0.8.1-71-gfff1dd9.zip).
Now cgminer 2.1.2 suddenly finds about 3 or 4 shares per minute.
The windows exe (p2pool_0.8.1_c7feb00.zip) works as expected, about one share per hour or so.
Today I tried installing Python 2.7 and using the source (forrestv-p2pool-release-0.8.1-71-gfff1dd9.zip).
Now cgminer 2.1.2 suddenly finds about 3 or 4 shares per minute.
The development version gives work to miners at a low difficulty so you can see how "well-tuned" your miner is by looking at the reject ratio over shorter periods of time.
should we be using the feb executable or the source?
i noticed yesterday I received probably 14 shares, but never received any coins, so now I'm confused as to what we should be running.
January 25, 2012, 04:14:18 AM
- Run p2pool:
- ...
- Source: python run_p2pool.py USER PASS
(Ubuntu 11.04)
Must run_p2pool.py be run with its distributed directory the current directory -- does it depend on other files in the distribution? Or can run_p2pool.py be copied to somewhere else?
January 25, 2012, 02:56:44 AM
thanks
for some reason when running cgminer from cygwin i was getting quite a lot of dead shares.
switched back to the regular cmd.exe for now
for some reason when running cgminer from cygwin i was getting quite a lot of dead shares.
switched back to the regular cmd.exe for now
January 24, 2012, 02:51:47 PM
from what i understand orphan shares are ones that were recieved too late by the other clients - and some other solution was accepted first.
but what are the dead shares?
but what are the dead shares?
They're essentially orphans, but they're special because they arrived at your p2poold from your miner _after_ your p2poold sent out a long poll. Essentially, you can blame dead shares on your miner configuration and orphan shares on internet latency.
EDIT: About the strange outputs, those are as Holliday explained. However, I plan to eventually embed that data into the merged mining header so we won't be bloating the blockchain as much.
January 24, 2012, 02:16:13 PM
Yeah come on gigavps... one of us... one of us... one of us... 
January 24, 2012, 01:02:26 PM
For all who are interested, BAMT can now be updated to include phoenix 1.7.4 which means that if you run BAMT, you can run on p2pool with a simple upgrade! This should mean that some pretty big mining farms can now run on p2pool.
Does that mean you are adding your farm?
January 24, 2012, 12:34:32 PM
from what i understand orphan shares are ones that were recieved too late by the other clients - and some other solution was accepted first.
but what are the dead shares?
but what are the dead shares?
January 24, 2012, 10:48:45 AM
probably for namecoin merged mining - a hash of the namecoin block
January 24, 2012, 08:51:40 AM
I've noticed that p2pool puts an invalid scriptPubKey in the first output of the generation transaction in its blocks. Looking at this block for example:
http://blockexplorer.com/block/0000000000000485d92d555cf92f865f14579394818d9b4030ec24569632e74f
the first output looks like this:
I'm not sure what it is, but both blockexplorer.com and blockchain.info call these outputs strange. Looks like a SHA-256 hash.
http://blockexplorer.com/block/0000000000000485d92d555cf92f865f14579394818d9b4030ec24569632e74f
the first output looks like this:
Code:
{
"value":"0.00000000",
"scriptPubKey":"ce32ad40ceff87531662999bb86b20d424d8018a199317681d1d4c79bc31f06d"
},
"value":"0.00000000",
"scriptPubKey":"ce32ad40ceff87531662999bb86b20d424d8018a199317681d1d4c79bc31f06d"
},
I'm not sure what it is, but both blockexplorer.com and blockchain.info call these outputs strange. Looks like a SHA-256 hash.
January 24, 2012, 07:21:45 AM
For all who are interested, BAMT can now be updated to include phoenix 1.7.4 which means that if you run BAMT, you can run on p2pool with a simple upgrade! This should mean that some pretty big mining farms can now run on p2pool.
If you switch over your BAMT farm, please donate to jedi95, forrestv and lodcrappo for making it possible to run BAMT and p2pool together!
If you switch over your BAMT farm, please donate to jedi95, forrestv and lodcrappo for making it possible to run BAMT and p2pool together!
January 23, 2012, 10:24:45 PM
The development version gives work to miners at a low difficulty so you can see how "well-tuned" your miner is by looking at the reject ratio over shorter periods of time.
Oh, ok. Thanks. January 23, 2012, 09:39:58 PM
Strange things going on here:
The windows exe (p2pool_0.8.1_c7feb00.zip) works as expected, about one share per hour or so.
Today I tried installing Python 2.7 and using the source (forrestv-p2pool-release-0.8.1-71-gfff1dd9.zip).
Now cgminer 2.1.2 suddenly finds about 3 or 4 shares per minute.
The windows exe (p2pool_0.8.1_c7feb00.zip) works as expected, about one share per hour or so.
Today I tried installing Python 2.7 and using the source (forrestv-p2pool-release-0.8.1-71-gfff1dd9.zip).
Now cgminer 2.1.2 suddenly finds about 3 or 4 shares per minute.
The development version gives work to miners at a low difficulty so you can see how "well-tuned" your miner is by looking at the reject ratio over shorter periods of time.
January 23, 2012, 05:02:12 PM
Don't forget that U is luck based.
January 23, 2012, 05:00:59 PM
But how do I tune my miner to maxamize shares and payout? Increase I to increase hash rate and U (shares/min) or decrease I to increase own efficiency?
I find that lower stales is better for payout than higher U/hashrate. AFAIK it depends on your exact hardware and how much of a difference it makes. Basically, you need to look at how U changes compared to how stales change. If U increases more than total dead+orphan (per min) then I think it makes sense for you to go with a higher U because total accepted (by p2pool, non-dead non-orphan) shares/min is higher. But I think most people find that U increases 5-10% for stales increasing 10-20%, meaning that overall p2pool good shares per hour is decreased by increasing I. In summary: YMMV. (I use dynamic I and haven't found enough difference to matter with either higher or lower I.)
Also, keep in mind that statistics for <100 p2pool shares is unlikely to be useful when comparing these relatively small changes.
Jump to: