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

It really looks more complicated than it is. All you need is a miner (IDK if GUIminer works), Bitcoind, and p2pool. There is a good step by step windows guide in this thread to get p2pool and bitcoind running, just throw in cgminer and your good. I'll try to write up a Linux guide today and post it, but I would encourage anyone interested to at least try an install and ask questions along the way.

One where I could literally copy paste the needed commands and click direct download links... sounds great! Id switch.  Although I think it would be better if this could somehow be integrated with GUIMiner... I would guess that alot of the bigger pools miners use GUIMiner because its easy (same reason they use the bigger pools, its easy)

No, I mean, it seems complicated, but I was surprised how simple it is. Once you know how to do it, it is really straightforward.

But like he said, we need which OS do you use (Windows or Linux), and how many mining rigs do you have (1 or many)?

I appreciate your patience, perhaps we should split a thread off however, serious coders are dealing with serious stuff here, I gather from skimming some of it.  It is not my intention to get in the way.

Yes, I'm aware. I just wanted to test the latest versions out.

qt is the GUI version right? I think that is addressed here https://bitcointalksearch.org/topic/m.696459 You just need to use bitcoind instead of bitcoin-qt.

Latest Win32 binary continues to crash bitcoin-qt, even 0.5.2.

Why don't we just start with what OS are you using and how many miners?

I am sorry, I had read the first post before I asked...might as well be in FORTRAN

I am 100% down with the politics/economics, I am good with hardware, I would rather chew glass than break on the software config...I will be here when y'all can port it out to an idiot.

You're talking to a guy still using GUIMiner

big names knocking around in here, I feel stupid asking, but I agree with the above poster that this is absolutely where we need to go...

Is there a "P2Pool for dummies" howto, preferably with a big red "start mining with P2Pool now" button?

I've been playing around with p2pool and I think it's a fantastic and absolutely necessary idea.  As bitcoin grows we really need to take precautions to preventing a 51% attack.  Any criminal/government/hacker with the resources could easily DDOS a subset of the major pools and compromise or take-over the largest remaining pool.  I sincerely hope p2p pooled mining becomes the majority of hashing power in the network this year.

Joined with all my miners.

In theory you can have multiple instances of p2pool that split and merge to keep difficulty low.

However, if a way can be found of adapting existing pools to not centralize the vote, and big pools implement it, that is a superb solution as well.

I was thinking about it too, but I discarded it thanks to my experience with "user agent" in current getwork API. It's almost impossible to filter any useful information because some miners are filling it with garbage. For example, people patching their miners don't change miner identification, so I often see that miner advertising itself as "poclbm/somenumber" behaves differently than real poclbm in this version.

But I think I found cleaner solution using prevhash. prevhash from local bitcoind is giving exactly the information which pool needs to check if client is using correct blockchain, even if he's using some weird home-baked miner with manually entered miner/bitcoind version. It's pretty long story, but I hope it will be clear from the proposed protocol (FYI built on the Stratum infrastructure).

I suppose GUIMiner is not fine for p2pool. You need the updated poclbm (for the 1 second thing) but...you can't update the miner of guiminer, so...

Well I haven't tested it but I believe this would be handled the same as a miner being on an orphaned chain or fork.
When a miner submits a share he also submits the data in the block header.  Other miners will see the incorrect prior block hash and reject it as an invalid share.  They won't know "why" it won't be a special p2sh detection it will simply be miner is using a wrong previous block so share is invalid.

The one exception would be if <51% of miners (by hashing power) have upgraded.  Then the consensus in the share chain would be the p2sh blocks are invalid and those miners would get no credit and invalids.



Correct.  It will be essential to ensure that at least 51% of miners upgrade.  If they don't then likely p2pool will quickly disentigrate (no different than a "normal pool" who's admin doesn't upgrade).

For example ars pool has been running on auto-pilot w/ admin mostly AWOL.  If that is still the case when p2sh is implemented then that pool will implode.



I'm not saying it's bad, I'm just sumarizing how I understand it.


Awesome.  It is something we need.  p2pool is a great resource but for small miners it will be an imperfect fit.  As p2pool gets larger the difficulty of shares gets higher.  At say 500 GH/s difficulty will be ~1200.  A 400MH/s miner will have an average share time of 3 hours +.  The 95% confidence around that is 1 to 12 hours.  That will be a tough sell. There are potential solutions but I think "traditional pools" aren't going away. 


Well with central control wouldn't it be possible to just include in the API a minimum supported version for the bitcoind & p2pool daemon equivalent?  Miner's report their bitcoind version and server rejects work from miners below minimum supported version. That won't prevent malicious user but it will prevent users accidentally running incompatible code.

Im using a cron job that polls the cgminer json rpc interface. Same with bitcoind.
For p2pool I parse the console output with a python expect script.
P2pool now has a json rpc interface too, but I hadn't time to use that yet.
The date is collected and written to a database on a webserver.

In case of an power outage i only notice that the last timestamp for the data on the webserver is old.

I also use OpenVPN & ssh to access my miners remotley



Thats not completely correct. P2pool payout is always based on the shares submitted in the last 24h. After a "round" ends the shares are not reset. If you only submit 1 share in 24h and there are 3 blocks solved in those 24h, you get 3 payouts. This decreases variance and makes p2pool hop proof.

Well, this is what I wanted to know. So shares won't be calculated for miners with "wrong" bitcoind version.


There is only the possibility that >50% of bitcoind's network will support p2sh, but <=50% of P2Pool users won't support p2sh. Then even user who updated his bitcoind will mine to the black hole, because his shares will be rejected by p2pool, although they would be valid on bitcoin network itself.

I'm not saying it's bad, I'm just sumarizing how I understand it.


I'm working on the mining protocol for the pools, where miners (workers) will have the power to choose transactions what they want to include into the block. I started to think about this seriously after I saw the criticism in op_eval and p2sh discussion that pool operators are holding too much power.

Actually I'm on the track of protocol which will allow full democracy of the bitcoin miners like in p2pool, but still with possible zero variance (even pps with difficulty 1 payout scheme), which is something what is missing on p2pool. It should be also DDoS resilient as there won't be any real benefit in attacking the server which will just collect shares and stats...

Thanks to this, I'm solving some potential issues with outdated miners. Of course witholding attacks (and other attacks) are still possible on the pools, but I just want to be sure that honest miners just using outdated software cannot break the pool itself. I think that I already found the solution, but I need to think about it a little more. But I hope that I'll publish my proposal soon...

True.  I misunderstood if that was your meaning.   

The issue of being on a fork is more a client/bitcoind issue.

As long as 51% of p2pool is updated then the users who are on the fork will have shares rejected by p2pool as they are not working on the proper block (and referencing the proper prior block).  User would see share count stay at 0 and that should provide a reason to upgrade.

In this respect the user is no different than a solo miner or pool which doesn't upgrade.

Much like p2sh support would require upgrades by 51% of mining pools (by hashpower) it would require upgrades by 51% of miners in p2pool (by hashpower).


Share the issues you are having.  p2sh will require changes but I don't think it creates any unique problems to p2pool.  As long as p2pool daemon is p2sh compatible AND 51% of hashpower is running p2sh aware version the p2pool should continue to function properly.

Oh, really? I didn't know that! :-P By partially solved block I meant a share or generally a proof of work, of course. I wanted to avoid "share" because it is used for diff1 work used in standard pools, but it doesn't matter now.


Thank you for the answer, this is exactly what I asked and also what I was affraid of. Actually there's big difference between block withholding and producing invalid blocks. For performing block witholding your malicious activity is needed to BREAK the pool. But when the bitcoin rules will change (like p2sh in the blockchain), your activity is needed to NOT BREAK the pool.

Maybe I'm missing something, but rolling P2Pool to p2sh will be really painfull unless I'm missing something. I'm asking because I'm working on getwork API replacement and I hit similar issue like I'm discussing here, so I'm asking how other people solved the issue.

[qupte]
Blocks wouldn't be rejected.  If the bitcoind is out of date it will see p2sh transactions as invalid and not include them.  The block produced would still be valid much like mining a completely empty (except coinbase) block is valid now.
[/quote]

Well, this isn't so easy. When there will be first p2sh transaction included in main blockchain, outdated client will make a branch because first block with p2sh won't be valid in outdated bitcoind...

Ha nice sales pitch from the guy running a no variance pool.  +1 on the marketing.