Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 796. (Read 2591916 times)

Um, not it's not.

Lol! imageban.ru is blocked in US government for "pornography" 

I think, well, if someone makes a simple guide for beginners ..with pictures.. . like this. I did it in Russian. https://bitcointalksearch.org/topic/800-ghs-p2pool-62698

If we remember that it's like we're rolling a dice with circa 6000 trillion sides (http://blockexplorer.com/q/hashestowin) 180 billion times per second (180 GH/s), and only a single number on that dice makes us a winner, the large variance makes more sense.

One Wilshire ftw.

I've been working on a graph of luck.. Here it is:

So yes, we've been rather unlucky recently, but before that we were very lucky at some times. The only solution is growth.

The split will probably be probably be Eastern hemisphere v.s. West or something similar. If you mine on the correct one, you'll have less stales than mining on the other, so there is incentive to switch (if we coordinate it so many switch at the same time).

The split would likely occur on a connection speed basis, so highly geographically-oriented. If you want to keep stales low, you'll select the closest "child" p2pool(s), similar to colocation - many financial firms handling forex and algo trading already buy locations as close as possible to major trunks just to gain a few ms in response time.

If long-range quantum tunnelling becomes economically viable, the rules change again and all bets are off.

So, interestingly, while traditional pools have incentive to keep growing indefinitely, p2pool has an incentive to keep growing to a point? When a P2Pool split happens, I hope the division is even, or even automatic based on contributed hash rate, since just creating a new pool and asking people to voluntarily switch will not work (I would rather keep mining on an overloaded pool that one with very little hash rate and gigantic variance).

Our unlucky streak continues

Now we need some days with 4-5 blocks to get at least back to our predicted average (3 blocks/day).

2012-02-08 : 1 block
2012-02-07 : 1 block
2012-02-06 : 1 block
2012-02-05 : 2 blocks
2012-02-04 : 1 block
2012-02-03 : 0 blocks
2012-02-02 : 2 blocks
2012-02-01 : 2 blocks
2012-01-31 : 2 blocks
2012-01-30 : 2 blocks
2012-01-29 : 2 blocks
2012-01-28 : 2 blocks
2012-01-27 : 1 block
2012-01-26 : 0 blocks
2012-01-25 : 2 blocks
2012-01-24 : 0 blocks

OK that's what I wanted to know, thanks for the info.

Here's one binary I found, though I haven't tested it, and is really old: http://oss.oetiker.ch/rrdtool/pub/contrib/rrdtool-1.2.12-python-2.4-win32.zip You might have to install all 32-bit Python and libraries to be able to use it... Because of how annoying rrdtool-python is, I'm planning to switch to PyRRD soon, which just calls rrdtool.exe. Waiting for that might be easier..


I don't really know much about Windows services.. but it looks like you could use the other approach mentioned on that thread, also seen here: http://support.microsoft.com/kb/137890 P2Pool doesn't require any special stop procedure and won't be hurt if you kill it.


This is correct, though if what happens we can simply split P2Pool into multiple pools. A single pool has no need for more than 10% of the total hashrate, so if we reach that point, we'll begin creating new, separate P2Pools.

Isn't making P2Pool big (let's say 50% of bitcoin total hash rate) a bad scenario? this will affect bigger variance(ofc not % one, you just get bigger timeframe in which that happens) and wait time for every miner, especially those small?
With 50% of total network speed and 10 000 miners (we have 10 000 ghashes/s so its even more than 20k GPUs mining) we will have 1 block every 20 minutes - so every 120 p2pool shares if i get them right. That will give miner a chance (assuming every miner is at same speed) of finding block equal to (20mins/10sec)/10 000 = 1.2% every 2 mined blocks in network.. to hit any block he will need to wait 166.66 blocks which is more than one day (1day = 144 blocks) for average chance of payout equal to his work.

P2P just lowers variance for everyone and speeds up everything by 60 times (1 share = 10s) comparing to normal bitcoin mining, but lets say we have 100k miners, what's then? Pooled mining will come back? Now think about those with Nvidia cards mining lets say 50mhash/s? Why they should join for 1 payout every week if they can get proportional payout every 30-120 minutes on big pools.
I know current pooled mining is dangerous and DoS capable, but isn't this idea going back to stone age?

Maybe i don't get idea properly. I just wanted to move here with my miners to support this project, but i see disadvantages in not so far future.

Please say i am wrong in these assumptions and calculations (i hope i am)! ! !



Sorry for my english, i hope you guys get whats the point
Jakub

Forrestv, any plans to make it possible to run P2Pool as a Windows service? Although bitcoind doesn't have the native capability, I found a script that would make it work here: https://bitcointalksearch.org/topic/bitcoin-service-wrapper-run-bitcoind-as-nt-service-43446

Perhaps you could modify that for P2Pool? I have already modified it for namecoind, but that was easy because it is so similar to bitcoind.

Side note, I would usually set up a *nix VM on my XenServer cluster for this, but I have run out of useable public IP addresses in my range, so I decided to install it on my existing web/mail server. Don't hate because of WinBlows, I use it because I have to (business hates *nix )

YYUUHUU!! ARIBA!!!  LOL

We broke 200 GH/s. Woot!

adding  700 MH/s to the pool

Thanks for the quick reply!

This has probably been asked before,but is it it better to have one instance of CGMiner for each GPU?

I'm using Windows x64. I installed Python 2.7 x64, Twisted x64, unzipped Zope.Interface x64, but when I try to see the graphs I get the following "Install python-rrdtool!". Searching Google for python-rrdtool didn't help to find a compiled version. Any help would be appreciated.

I'm on p2pool since yesterday, nice piece of work, it is quite smooth to install and run. I am contributing ~1720 Mhash/s right now.

I especially like the graphs.