[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[Rubberduckie]

(I'm getting 33% stales atm with -i8 -g1 and powertune @ 20)

[ThiagoCMC]

Hi!

 I just "git pull" p2pool and I'm seeing:

Code:

2012-02-12 17:15:34.299531 > Error while calling merged getauxblock:
2012-02-12 17:15:34.299732 > Traceback (most recent call last):
2012-02-12 17:15:34.299992 > Failure: twisted.internet.defer.TimeoutError: Getting http://127.0.0.1:7333/ took longer than 5 seconds.

But my namecoind is running normally...

Any thoughts?!

Never mind...

[ThiagoCMC]

My sencond block for P2Pool!!

Awesome! I find 2 blocks within one week!!! With only ~6GHash!

Code:

2012-02-12 05:34:41.298564 GOT BLOCK FROM MINER! Passing to bitcoind! bitcoin: 6ce97b20b9c71d2f686d2d5cf2e0b1d4e9ef9f2196c06cd0909
2012-02-12 05:34:41.305530 GOT BLOCK FROM PEER! Passing to bitcoind! a5065536 bitcoin: 6ce97b20b9c71d2f686d2d5cf2e0b1d4e9ef9f2196c06cd0909

hihihihi!!

[LightRider]

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

Edit: Of course, one of the other issues that this would help with is latency, which I didn't mention originally, but is a big reason to base it off of geoip.

[ThiagoCMC]

I'm thinking in go to solo-mining!! LOL

Code:

2012-02-12 23:32:23.111945 GOT BLOCK FROM MINER! Passing to bitcoind! bitcoin: 6b0770b31d1ee4150d78cd738b028b3a904aa30ed992c2ea1a4
2012-02-12 23:32:23.144027 GOT BLOCK FROM PEER! Passing to bitcoind! 4ed95f7f bitcoin: 6b0770b31d1ee4150d78cd738b028b3a904aa30ed992c2ea1a4

I never find so many blocks within a so little time window...

[ThiagoCMC]

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

I have two questions for you:

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

2- This reallocation to sob-pools can be done automatically, right?

Cheers,
Thiago

[twmz]

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

Much sooner than that.  Some might say it is already bad for small miners.  But I suppose it depends on what you consider "bad for small miners"?  If it takes a typical miner several hours to find a share, that is going to lead to painful variance.

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

• The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
• The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
• The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

Here is a large version: https://i.imgur.com/77zM9.png

[kano]

Thinking about the growth problem, I was contemplating solutions that might be feasible. I began thinking about how we could evenly and fairly distribute hash power so that everyone is in a sub-p2pool that would benefit both them, and the bitcoin network at large. I imagine a system where the a miner's geolocation was determined, either using geoip services, or allowing the miner to specify their location, and then using that data to connect to others in the same graticule (1 degree x 1 degree area on the globe). If that graticule does not provide enough hashing power to produce blocks on a desired basis, then that subpool will connect with neighboring graticules. Each subpool is represented in the hash chain by a hash of all the graticules that the subpool serves. Subpools would have to determine if they should reconfigure themselves on a certain timescale to redistribute hashing power as needed. I know it sounds complicated, but I really think it would be an interesting solution to a unique problem.

I have two questions for you:

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

2- This reallocation to sob-pools can be done automatically, right?

Cheers,
Thiago

Interesting, the reduction in variance caused by pools is in fact a problem for P2Pool due to the amount of network data to deal with a pseudo-chain ...
P2Pools solution is already to increase the variance (block difficulty much > 1)
But suggesting to reduce the size of the actual pools themselves makes P2Pool sound like it's going to end up only being good for big hash rate miners.
Having to increase the variance (both ways) to solve the problem sounds bad IMO ...

[twmz]

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

• The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
• The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
• The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

On the other hand, the higher the pool hash rate, the sooner your found-share turns into a payment.  Currently, if you are a 200 MH/s miner and find a share (about once every 3-4 hours on average), you may have to wait 8-10 hours for the pool to find a block and turn that share into BTC.  If the pool hashrate gets up to 1TH/s, you may only find a share every 13-14 hours, but the pool will likely find a block within an hour or two and turn that share into a payment.

Variance math hurts my head and I can't wrap my brain around how to quantify how the two competing variances (pool variance interacting with miner variance) contribute to a miner's overall payment variance.  Need someone like Meni to enlighten me, I guess.

[ThiagoCMC]

So, in the end of the day, what is the best approach for miners?!

Can something like P2Pool be built without this pseudo-chain?! Something complete new... Between actual pools and P2Pool... I guess...  O_o

[marcus_of_augustus]

So, in the end of the day, what is the best approach for miners?!

Can something like P2Pool be built without this pseudo-chain?! Something complete new... Between actual pools and P2Pool... I guess...  O_o

Based on that nice plot above of "twmc" it seems that the 'optimal' solution will be p2pools will split up according to size of the miners.

I.e. bigger miners will go in one p2pool that has time-of-share and time-of-block nearly the same, medium sized miners will go in separate pool with similar set-up and smaller miners will go in another pool with similar time-of-share to time-of-block ratio.

Maybe throw in some variation due to location of miners and network latency to skew it a little.

So anyone want to start another p2pool for "less than big" miners?

[chunglam]

1- WHEN the P2Pool difficulty will be bad for small miners? When we reaches 1THash, 2THash, 4THash?!

I made a chart to illustrate what happens as the pool gets larger.  The chart is based on an overall bitcoin difficulty of 1.4 million (approx what we are now and will be for the next round).

Here is what the chart shows:

• The solid red line is the average time for the pool to find a block as the pool's hashrate grows.
• The dotted lines are the average time for miners of various sizes to find a SHARE as the pool's size increases and the share difficulty increases with it.
• The point where a dotted line crosses the solid red line is the point at which the average time for a miner to find a share becomes larger than the time for the pool to find a block.

On the other hand, the higher the pool hash rate, the sooner your found-share turns into a payment.  Currently, if you are a 200 MH/s miner and find a share (about once every 3-4 hours on average), you may have to wait 8-10 hours for the pool to find a block and turn that share into BTC.  If the pool hashrate gets up to 1TH/s, you may only find a share every 13-14 hours, but the pool will likely find a block within an hour or two and turn that share into a payment.

Variance math hurts my head and I can't wrap my brain around how to quantify how the two competing variances (pool variance interacting with miner variance) contribute to a miner's overall payment variance.  Need someone like Meni to enlighten me, I guess.

According to P2Pool Wiki

Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller.

So you still got payout as long as your shares are still in sharechain of last n shares(3 times the average work required to solve a block, or 8640, whichever is smaller).

[kano]

...
According to P2Pool Wiki

Each share contains a generation transaction that pays to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 8640, whichever is smaller.

So you still got payout as long as your shares are still in sharechain of last n shares(3 times the average work required to solve a block, or 8640, whichever is smaller).

Actually that's a rather interesting definition (yes I've seen it before) but realised something else about it:
Since ... the average work required to solve a block is adjusted based on the number of miners (bigger difficulty means less shares per block) and the average work/shares per block drops as more people mine and thus it should pretty much always be 8640 once it gets there.
So you'll need at least one in the last 8640 shares to get paid anything ...
Hmm ... actually it's already almost down to 8640 now isn't it? (by calculation)

Edit: Yeah once share difficulty reaches 470
Edit2: It's 468 at the moment?

[Ente]

Based on that nice plot above of "twmc" it seems that the 'optimal' solution will be p2pools will split up according to size of the miners.

That is my first thought too.
A big pool, with high share-difficulty and with the bigger miners.
A sub-pool, with its own sharechain, where small miners work. The sub-pool would request work from the big pool, just as the sub-pool would be one of the bigger miners.

That way all miners would have payouts in short timeframes, and the small miners would have fine-grained enough proof-of-their-work too.

The small miners would have one (or double) the hops, with higher latency accordingly.
There might be more centralization with this setup too.

Ente

[1Pakis]

Is that normal for ~370Mhs?

[Regex]

https://i.imgur.com/6MJLY.png
Is that normal for ~370Mhs?

yes.


Btw: 3 blocks in 1 hour, wth 

[Ed]

my logfile is fast growing 
how I can cut it?

where I can see full run_p2pool.exe options list?

[1Pakis]

Is that normal for ~370Mhs?

yes.


Btw: 3 blocks in 1 hour, wth 

It 's actually 3 shares in 11 min 8 sec
But over a period of ~28 hour only 12 shares.
According to reported time per share from p2pool I should get about 12 to 18 shares per 24 hours.

[chunglam]

10 blocks in last 24 hours

[Regex]

https://i.imgur.com/6MJLY.png
Is that normal for ~370Mhs?

yes.


Btw: 3 blocks in 1 hour, wth 

It 's actually 3 shares in 11 min 8 sec
But over a period of ~28 hour only 12 shares.
According to reported time per share from p2pool I should get about 12 to 18 shares per 24 hours.

Are you aware of the term "variance" ?