Topic: p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival] - page 18. (Read 35513 times)

Output is a mess, but 1.5.8, but it works (more or less)
From p2pool side lots of warnings type:

1.5.8 checked, output below

cgminer 1.5.8 seems to work for me but not, as you note, the newer versions.  I was getting very low stale rates (usually around .12-.18) until recently, where I'm getting around .4 rather than the ~.2 median - not sure what changed but at least it still works?

Nice, maybe is also a good idea to create something like best practices for p2pool ... I belive that more experienced users could share their knowledge regarding best miners & settings to optimize performance and (possibly) decrease amount of stales.
For example - after two days of minning for p2pool i can tell that diablo seems to be the best option (patched version of course), however it's is not my favourite because its generating unnecesary burden on CPU (java - around 20%) and other weird behaviours, so I am looking forward for new phoenix...

Screenshot from today (velocity of rig with phoenix: ~1450, diablo ~1390, p2pool after few hours shows values between 850-1200 MH/s ):

In case of phoenix published with patch so far - amount of stales seems to be higher than in case of diablo, I have been told that it can be improved by decreasing parameter AGGRESSION from 12 to 7, but after that my cards works on 80-85% so its waste of resources and i don't like it at all

Cgminer - 2.x.x does not work (older version not checked) despite of info on p2pool mainpage. Checked with forrestv-p2pool-19b86ed.tar.gz (https://github.com/forrestv/p2pool/tarball/19b86ed6d0b3c3a98f6199db7377a0e170365cfd)

Fellow miners - please do not hesitate to share with us ... newbies , and remember that it also should help to avoid annoying and recurrent cuestions from us on IRC ..

Thats all for now, hoping that it will help someone ... Regards

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.

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 too think this is a great idea and would be willing to start mining with the network if the phoenix patch makes it to an official release and on to the bamt stack. Also, is there anyway to streamline the setup of p2pool? The setup while not difficult, still makes me hesitate, which IMHO will keep others from coming on board.

I believe that cgminer currently does not work with P2Pool. Any plans to correct it in the nearest future ?

PS. P2Pool is really a great idea, hoping that with time will develop and grow ...

Two new blocks, all with transactions:

http://blockexplorer.com/block/00000000000004dcfbf2bf4146708696befebc903c174840daedc9ff139d5a80
http://blockexplorer.com/block/00000000000004082eab788a57ef75be1a107cd87d320ad9cf246bea4cf383ce

This brings p2pool to 7 total blocks, 3 of which have transactions.

P2Pool found another block, and this is the first one that includes transactions:

http://blockexplorer.com/block/00000000000002436bd2ae60d67d6fc0dce44deba2ad739619a3d364f6283e64

New release: 19b86ed

Windows binary: http://u.forre.st/u/ljordepl/p2pool_win32_19b86ed.zip
Source download: https://github.com/forrestv/p2pool/tarball/19b86ed6d0b3c3a98f6199db7377a0e170365cfd

Changes:

• Completed support for inclusion of transactions - depends on the getmemorypool patch to bitcoind (patched bitcoin distribution will soon follow)
• Removed logic to transition share period from 5 to 10 seconds
• Better logging for work requests
• Better log file handling - now always appends, and truncates from the start when the log file size reaches 100MB
• Fixed small bug that happens while downloading shares that contain a block solution

TODO for next release:

• Optimize CPU time used and latency caused
• Rework "donation" system

well, you would need to run your own.  unless you use the public p2pool node: https://bitcointalksearch.org/topic/18-ghs-wwwbitaramacom-the-first-p2pool-public-node-38421

And yes, if this problem is fixed -- p2pool includes user transactions in blocks -- then the objection is removed.

forrestv was indicating on IRC that a fix is being deployed... we'll see from the next block p2pool generates.

Sorry, but that is just spin.

p2pool delays transactions, running directly counter to the service bitcoin users want to provide.

This also sets an awful precedent:  imagine more miners following p2pool's examples, or p2pool gains hash strength.  There would be huge transaction delays.

Failing to include transactions is harmful to the network, plain and simple.

No, it isn't. P2Pool is contributing to the security of the network by building on existing blocks.

As for delaying transactions, P2Pool running without including transactions is exactly the same as everyone using P2Pool just not mining at all. (Until the next difficulty change, at least.) Block generation is independent, so the average time to the next non-p2pool block is: 10 minutes / (1 - p2pool_hash_rate/total_hash_rate), which is currently equal to 10.01 minutes.

One hopes so.

Until then, p2pool is actively DoS'ing the bitcoin network, by delaying transactions until a non-p2pool miner builds a block.

That is very harmful to the network.

That's good to hear that it's flexible incase it need changes in the future.

By solved blocks I assume you mean solved shares?
I would've thought setting it proportionate to shares would be easiest, but let me know which one you decide!

The p2pool node just follows your bitcoind's transaction acceptance rules. Patch it and you'll change what transactions p2pool includes. P2Pool just requests a list of transactions to include from bitcoind; it has no knowledge of their individual fees.


I like this idea, and the p2pool protocol can be changed relatively easily (recently we switched from a 5 second share period to a 10 second share period with this change).

This could be done in two ways: Each user could set the proportion of their individually solved blocks to donate, or each user could set the proportion of their work to donate. They should be equivalent in the long run, so I'm mainly considering which is easier to implement.

Everyone pays for the network infrastructure themselves, so there is central server, no central website, no monitoring or intervention required...

Yeah I'd happily donate 2% of my shares to this project purely because of the massive benefits it gives.
Also would I be correct in saying that since it's p2p there's no bitcoind server to pay for?