Switched over last night. I had been waiting for pheonix to suport it since I put so much time into tweaking on that miner. The instructions were a little hazzy and the version numbering in hex seems confusing. But So far so good. I occasionaly get communication errors between the P2Pool and bitcoind (on the same machine) but I am going to research it more.

in the miner i get 2 shares/minute and less than 1% rejectedin p2pool i get a share about once an hour or 2, with ~10% orphans and 0 dead

My guess is that the miner is counting as "accepted" everything that meets Difficulty 1 (the usual share difficulty for pools), even though an actual share on p2pool is harder than Difficulty 1. The same thing happens with the FPGA miner I use.

If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the culture of naive fools and conmen, the former convinced that BTC is a magic box that will turn them into millionaires, and the latter arriving by the busload to devour them.

It walks users through the installation process in a quick, precise manner. It includes the ability to configure the p2pool mining address, add additional cgminer flags, and generates an easily modified .bat file which launches both p2pool and cgminer.

It walks users through the installation process in a quick, precise manner. It includes the ability to configure the p2pool mining address, add additional cgminer flags, and generates an easily modified .bat file which launches both p2pool and cgminer.

This is cool, but what would be really awesome is if you could script it with NSIS - it is a scripting language that is designed for nothing but installing other programs. Lots of error handling (if you choose to use it) and plugin capability. Reasonably easy to learn, too.

Moved ~ 1.6 gh/s to p2pool this weekend from Slush, and if all goes well this week, I'll be moving another 2.5 gh/s over next weekend.. I'll have to say, Slush hasn't had any DDOS attacks recently, and I trust he hasn't been holding any block rewards for himself, but decentralized mining pools are a natural progression for a decentralized application like bitcoin. Great work guys! I'm a little confused about where the payments come from though... Does the p2pool client force multiple payments from the block solver's bitcoin client to all miners in the pool? Is another bitcoin client built into the p2pool binary?

It walks users through the installation process in a quick, precise manner. It includes the ability to configure the p2pool mining address, add additional cgminer flags, and generates an easily modified .bat file which launches both p2pool and cgminer.

I'm a little confused about where the payments come from though... Does the p2pool client force multiple payments from the block solver's bitcoin client to all miners in the pool? Is another bitcoin client built into the p2pool binary?

The found-block directly includes the appropriate payments in the coinbase (the transaction that generates the 50 BTC). Instead of the 50 BTC going to one address, it goes to all of the addresses of people that have mined shares in the last N shares (usually 8640) relative to how many shares they have mined.

According to the blockexplorer link, 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 is associated in the block chain with the public key that is used for donations via the --give-author p2pool command line option. You can see this hexadecimal public key in the p2pool source code yourselves, where it is stored in the SCRIPT variable near the middle of data.py (bitcoin 'script' annotations are mine):

According to the code, this address will always receive at least 1 satoshi per block, plus any donations (~0.25Btc per block w/default settings) and remaining satoshis that are left over after divvying the block's reward & fee amongst the p2pool miners.

So unless the code gets changed, you can expect the 1Kz5QaUPDtKrj5SqW5tFkn7WZh8LmQaQi4 address to be present in the "To" side of all coins generated by p2pool.

After I go to http://127.0.0.1:9332/graphs/ it says I need to install python-rrdtool but I can only find source distributions and I'm really too lazy to compile it myself (it never runs out of the box and just ends up costing a lot of time). Are there binary distributions of this project?

After I go to http://127.0.0.1:9332/graphs/ it says I need to install python-rrdtool but I can only find source distributions and I'm really too lazy to compile it myself (it never runs out of the box and just ends up costing a lot of time). Are there binary distributions of this project?

dont see any problem therework is restarted when a share is found by others - about once in 10 secondsthe accepted shares reported by the miner are low difficulty - ~1 , this can indicate if you have any problems with rejectsthe actual shares that count are reported in the p2pool client

I'm a little confused about where the payments come from though... Does the p2pool client force multiple payments from the block solver's bitcoin client to all miners in the pool? Is another bitcoin client built into the p2pool binary?

The found-block directly includes the appropriate payments in the coinbase (the transaction that generates the 50 BTC). Instead of the 50 BTC going to one address, it goes to all of the addresses of people that have mined shares in the last N shares (usually 8640) relative to how many shares they have mined.

So, I've got my 2 Windows miners(1x2x5870 & 1x2x6970) chugging along at about a 1% reject rate with phoenix 1.7.5. I tried to drop my 2.5 gh/s minecart in, with the same version of phoenix but running the last release of linuxcoin. I'm getting about 30% - 50% reject rate on all 7 gpus (3x5970s & 1x5830) Same miners pointing at Slush and I'm down at 1% reject rate. Does the P2P client have issues with nodes that have too many GPUs? Maybe I need to update the ATI drivers...

I'm running p2p client on a central machine in my network; I would try running another p2p instance on the minecart but I'm running the OS off a 4gb USB stick and I'm not sure it could handle the current size of the Bitcoin blockchain.

I tried to drop my 2.5 gh/s minecart in, with the same version of phoenix but running the last release of linuxcoin. I'm getting about 30% - 50% reject rate on all 7 gpus (3x5970s & 1x5830) Same miners pointing at Slush and I'm down at 1% reject rate. Does the P2P client have issues with nodes that have too many GPUs? Maybe I need to update the ATI drivers...

I run a single rig with 5 GPUs and phoenix and get about 5% reject. Check your AGRESSION option. It needs to be lower for p2pool in order to get lower stales. I was getting 20-30% as well and dropped the AGRESSION from 9 down to 7 and reject rate dropped like a rock. I don't know why this is necessary, but it seems to be.