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

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: chunglam on February 13, 2012, 01:36:06 AM

...
According to P2Pool Wiki

Quote

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?

chunglam

donator

Activity: 229

Merit: 106

Quote from: twmz on February 13, 2012, 12:07:10 AM

Quote from: twmz on February 12, 2012, 11:49:22 PM

Quote from: ThiagoCMC on February 12, 2012, 09:23:54 PM

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

Quote

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).

marcus_of_augustus

legendary

Activity: 3920

Merit: 2349

Eadem mutata resurgo

Quote from: ThiagoCMC on February 13, 2012, 12:24:13 AM

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?

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

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

twmz

hero member

Activity: 737

Merit: 500

Quote from: twmz on February 12, 2012, 11:49:22 PM

Quote from: ThiagoCMC on February 12, 2012, 09:23:54 PM

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.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ThiagoCMC on February 12, 2012, 09:23:54 PM

Quote from: LightRider on February 12, 2012, 08:14:08 PM

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

hero member

Activity: 737

Merit: 500

Quote from: ThiagoCMC on February 12, 2012, 09:23:54 PM

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: http://i.imgur.com/77zM9.png

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

Quote from: LightRider on February 12, 2012, 08:14:08 PM

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

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

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... Tongue

LightRider

legendary

Activity: 1500

Merit: 1022

I advocate the Zeitgeist Movement & Venus Project.

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

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

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!!

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

Quote from: ThiagoCMC on February 12, 2012, 02:17:09 PM

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...

Rubberduckie

legendary

Activity: 1442

Merit: 1000

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

Rubberduckie

legendary

Activity: 1442

Merit: 1000

What setting do you guys use for "powertune" in cgminer?

ThiagoCMC

legendary

Activity: 1204

Merit: 1000

฿itcoin: Currency of Resistance!

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?!

wachtwoord

legendary

Activity: 2324

Merit: 1125

It's 952 MB < 1GB, and the index is 352 MB

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: ThiagoCMC on February 12, 2012, 01:04:43 PM

Quote from: kjj on February 12, 2012, 12:29:00 PM

I've been working on a self-contained network-provisioned bitcoind + namecoind + p2pool USB stick. I had horrible problems with bitcoind getting stuck for minutes at a time.

I came up with a solution, but it isn't pretty. I run bitcoind entirely out of RAM now.

I have precisely this setup working here...
BTW, I also have Devcoin and Litecoin working... My USB stick have 8G...
My machine have 1G of RAM...

Cheers!
Thiago

No, you are doing something else. The bitcoin blk00001.dat file itself is over a gigabyte now, and the index is a couple hundred megs more.

m3ta

sr. member

Activity: 435

Merit: 250

Quote from: ?? on ??

Quote from: m3ta on February 12, 2012, 01:25:13 PM

Quote from: Regex on February 12, 2012, 01:10:38 PM

No block found for like 4h, something seriously stinks here.

Roll Eyes

We found 7 blocks in 6.5 hours.
Yeah something stinks here: your concepts of "luck" and "variance".

I'd bet 100 BTC, if I was a betting man, that he was being sarcastic.

I saw his smiley too. Didn't you didn't see mine? heh

Red Emerald

hero member

Activity: 742

Merit: 500

Quote from: ThiagoCMC on February 12, 2012, 01:04:43 PM

Quote from: kjj on February 12, 2012, 12:29:00 PM

I've been working on a self-contained network-provisioned bitcoind + namecoind + p2pool USB stick. I had horrible problems with bitcoind getting stuck for minutes at a time.

I came up with a solution, but it isn't pretty. I run bitcoind entirely out of RAM now.

I have precisely this setup working here...
BTW, I also have Devcoin and Litecoin working... My USB stick have 8G...
My machine have 1G of RAM...

Cheers!
Thiago

Wonder what that will do to the lifespan of your flash drive.

Might be faster to install a small HD for the blockchains but still run the OS from the flash drive. Of course if you are doing that, might as well just run the whole OS from the HD...

m3ta

sr. member

Activity: 435

Merit: 250

Quote from: Regex on February 12, 2012, 01:10:38 PM

No block found for like 4h, something seriously stinks here.

Roll Eyes

We found 7 blocks in 6.5 hours.
Yeah something stinks here: your concepts of "luck" and "variance".

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