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

[jonnybravo0311]

Sorry what is this 3 day PPLNS period?  Is that how p2pool works?

Yes, that's how p2pool works.  The sharechain counts the previous 8640 shares for payment when a block is solved.  Every share is about 30 seconds, so that's where the 3 days comes from.

[1715602407]

1715602407

[1715602407]

1715602407

[1715602407]

1715602407

[windpath]

You're right.  I glossed over it, as it didn't look immediately decipherable to me.    Looking at it now..

The immediate problem that jumps out at me is the difficulty changes at least twice a month, closer to three.  You need to store some value for each block as it happens, and then calculate it across your range when you display it.  This is what I do for Eligius:

For each block, store:
- average solve time
- actual solve time
- timestamp of the block

then some SQL:

for last 10 blocks:

SELECT sum(AvgSolveTime) / sum(ActualSolveTime)
FROM Luck
where Height >=
(select min(Height) from
(SELECT top 10 Height from Luck where Height <> 0 order by blocktimestamp desc));

for last 12 hours:

Select Sum(Luck.AvgSolveTime) / Sum(Luck.ActualSolveTime)
FROM Luck
Where BlockTimeStamp > (Now - 12 hours);

And so forth.  You can see the code in github for M's Pool Monitor.

M

EDIT: Then do a sanity check against a presumably known good source, like p2pool.info.

Yea, considered diff changes when writing the collector code (before adding the p2pool stats page...) Right now it bases it on current diff, would not be hard to add historical and store future back to beginning of luck calculations...

I assume the 30 day average diff would be most accurate?

Also, how best to calculate diff changes when a block spans 2 diffs? Is it the average of the 2 diffs, or the diff when block was found...

- average solve time

When is this calculated from?

[mdude77]

Yea, considered diff changes when writing the collector code (before adding the p2pool stats page...) Right now it bases it on current diff, would not be hard to add historical and store future back to beginning of luck calculations...

I assume the 30 day average diff would be most accurate?

I don't think so.  You have to use the difficulty at each block.  Just like you have to use the pool hash rate at each block.

Also, how best to calculate diff changes when a block spans 2 diffs? Is it the average of the 2 diffs, or the diff when block was found...

It would be when the block is found.  I think if you were to average, it'd have to be a weighted average, if you will.  So if you had 24 hours at one difficulty, and 12 hours at the next, the 24 hours would "weigh" more in the average.  While I think it's not technically 100% correct (Organ, are you here? ), it's a lot easier just to use the difficulty at the time it was solved.

- average solve time

When is this calculated from?

That's how long, on average, it should take for the block to be solved, at the pool hashrate at that time and current difficulty.  Something like:

network_difficulty * 2^32 / pool_hashrate

So if you know how long it should take (in seconds), and you know how long it really did take (in seconds), then it's simple division to see if your luck was good or bad:

AvgSolveTime / ActualSolveTime

If both are equal, you're at 100% luck.
If AvgSolveTime is higher, then you're above 100% luck.
If AvgSolveTime is lower, then you're below 100% luck.

To span across blocks, you divide the sum of one by the other:

SELECT sum(AvgSolveTime) / sum(ActualSolveTime)


Disclaimer: as far as I know my numbers are right, and they jive with the more limited info Eligius shows.

M

[mdude77]

Can someone help me understand this please?

Calculator says 1TH = ~0.03 BTC per day
This Difficulty
per Day   0.02900884 BTC   $18.06


This 1TH miner here is generating around 0.07 BTC per day
http://minefast.coincadence.com/miner.php?id=15TiNiu2ZUjrYKskn9AsbznAgtab19KH84

This guy has more power (1.4TH) and is making less?
http://minefast.coincadence.com/miner.php?id=1Po4Fa4drFtaDZ2Rr51mVs26L9bADJqZBG

I'm confused

There are all sorts of things that can affect expected payout.  One is luck.  Another is how long that user has been here.  If both users are past the 3 day PPLNS period, then the numbers are probably caused by luck, but could also be an error on the website.

M

Another possibility is that the "smaller" miner is actually spread across multiple nodes with the same address.  I do that with rigs pointed at my personal node in the US or ones in EU or Asia depending depending on lowest latency and distance.  Also failover nodes factor in too.  So 1TH may not actually be just 1TH, but instead just 1TH on Coincadence.

I'm pretty sure Coincadence is looking at p2pool stats, which means it's everything for that address, not just what's on that node.

M

[mdude77]

Can someone help me understand this please?

Calculator says 1TH = ~0.03 BTC per day
This Difficulty
per Day   0.02900884 BTC   $18.06


This 1TH miner here is generating around 0.07 BTC per day
http://minefast.coincadence.com/miner.php?id=15TiNiu2ZUjrYKskn9AsbznAgtab19KH84

This guy has more power (1.4TH) and is making less?
http://minefast.coincadence.com/miner.php?id=1Po4Fa4drFtaDZ2Rr51mVs26L9bADJqZBG

I'm confused

I think there's an error somewhere in the hashrate calculation on coincadence.  The same data is available on p2pool.info (check the 3rd tab "active users").  It shows the first address clocking in at almost 3 TH/s, and the second one at 1.5 TH/s.

M

EDIT:

One more thing to remember.  It took me the longest time to figure out how the Bitcoin protocol knows the network hashrate.  I believe the answer is it doesn't. 

Instead, it makes an educated guess.  If X number blocks are being solved in Y time at Z hashrate, then the network hashrate is approx H.  Obviously with larger numbers, the more accurate that value is, but it's still an estimate.

P2pool is no different.  If a given address has X numbers of shares on the chain in Y time (which I believe is fixed at ~ 3 days), with the known hashrates at the time of each share, then the hashrate for that address is approximately H.  Since luck will cause the number of shares to vary, the estimated hashrate for that user will vary. 

Apply that logic to the entire sharechain, and you can see why the pool hashrate appears to jump all over the place.  It isn't really jumping that much.  What you're seeing is the affect of variance (ie luck) on the sharechain.

[jedimstr]

Can someone help me understand this please?

Calculator says 1TH = ~0.03 BTC per day
This Difficulty
per Day   0.02900884 BTC   $18.06


This 1TH miner here is generating around 0.07 BTC per day
http://minefast.coincadence.com/miner.php?id=15TiNiu2ZUjrYKskn9AsbznAgtab19KH84

This guy has more power (1.4TH) and is making less?
http://minefast.coincadence.com/miner.php?id=1Po4Fa4drFtaDZ2Rr51mVs26L9bADJqZBG

I'm confused

There are all sorts of things that can affect expected payout.  One is luck.  Another is how long that user has been here.  If both users are past the 3 day PPLNS period, then the numbers are probably caused by luck, but could also be an error on the website.

M

Another possibility is that the "smaller" miner is actually spread across multiple nodes with the same address.  I do that with rigs pointed at my personal node in the US or ones in EU or Asia depending depending on lowest latency and distance.  Also failover nodes factor in too.  So 1TH may not actually be just 1TH, but instead just 1TH on Coincadence.

I'm pretty sure Coincadence is looking at p2pool stats, which means it's everything for that address, not just what's on that node.

M

Nope.  A few times today I had about 2TH on Coincadence (failover) and 1.5TH on my node.  Coincadence only showed my hashrate for the times my miners were on it and only for those particular rigs.  Otherwise it would have shown a steady rate of more hashrate. When my miners haven't been on Coincadence for awhile, I see the generic stat page without a chart that people see when they don't mine directly thru Coincadence.

[ceslick]

Anyone tried a Rockminer R3 500 on p2pool yet?

Looking at those as an option instead of S3's for now.

[windpath]

Nope.  A few times today I had about 2TH on Coincadence (failover) and 1.5TH on my node.  Coincadence only showed my hashrate for the times my miners were on it and only for those particular rigs.  Otherwise it would have shown a steady rate of more hashrate. When my miners haven't been on Coincadence for awhile, I see the generic stat page without a chart that people see when they don't mine directly thru Coincadence.

Was wondering who that was, happy to have ya visit jedi

So to avoid further confusion (and when I have the time I'll add this to the site somewhere), there are 2 completely different hash rate values reported on 2 different pages of Coin Cadence:

1. On Node Miner Rates, reported under the "Active Miners" tab on the node dashboard, these are relatively accurate and are only reported for miners on my node: http://minefast.coincadence.com/index.php

If you are mining on my node this same data is presented on the miner dashboard here: http://minefast.coincadence.com/miner.php

If you are not mining on my node there is no hash rate data on the miner dashboard.

2. Global miner estimated hashrate, reported under the "Active Miners" tab on the Global Pool Dashboard here: http://minefast.coincadence.com/p2pool-stats.php

From the link on that page "how we estimate hashrate":

Estimated hash rate is NOT an accurate report on a given miners actual hash rate, it is heavily affected by luck/variance and does not take doa/stale shares into account.

If your reported rate is higher then actual rate you are currently lucky in finding shares.

It is calculated as follows:

estimated_hash_rate = (current_payout / block_value) * pool_rate

current_payout = Miner current expected payout.
block_value = The total reward for the block this node is working on.
pool_rate = P2Pools reported /rate.

(results formated to GH/s)

I like this way of doing it as it lets a miner see how lucky/un-lucky they currently are displayed as an "effective" hash rate. The total of all miners on this tab will always equal the global pool rate as reported by p2pools /rate...

I wont be able to play around with the 7 day luck until thursday, I'll report back when its updated, any other suggestions are always welcome...

[abdullahadam]

Awesome work windpath
 

Can I ask,  what is the end game for hosting a 0% p2pool node?  Obviously it costs you money.

One is to support a decentralized bitcoin I am sure, but what else are your goals?

[norgan]

I like this way of doing it as it lets a miner see how lucky/un-lucky they currently are displayed as an "effective" hash rate. The total of all miners on this tab will always equal the global pool rate as reported by p2pools /rate...

I wont be able to play around with the 7 day luck until thursday, I'll report back when its updated, any other suggestions are always welcome...

yeah I like that too, but I have my local cgminer/bfgminer showing me more acute hash rates. both can be useful, you just need to remember that network hash rates are more of an average hash rate over a certain time.

[nreal]

I was talking about walletaddress/10000000 as minimium setting with 1th hardware

I have 4 ants pencilmodded to 580gh -- 150 + 150 +140 +140

p2poolinfo tells me that my hashrate is 1Lesbkz3Th7Xk4xJEw6SGyLGwLF6GubNwd    6285 GH/s

So im lucky 

[Muhammed Zakir]

Can I mine to an address which isn't in my wallet with below command?

Code:

-a BITCOIN_ADDRESS : Mine to this address instead of requesting one from Bitcoin.

Kindly,
        MZ

[PatMan]

Can I mine to an address which isn't in my wallet with below command?

Code:

-a BITCOIN_ADDRESS : Mine to this address instead of requesting one from Bitcoin.

Kindly,
        MZ

Yes, you can have payments sent to any address you like  

Edit: But not an exchange address as mdude rightly points out below - thanks mdude 

[mdude77]

Can I mine to an address which isn't in my wallet with below command?

Code:

-a BITCOIN_ADDRESS : Mine to this address instead of requesting one from Bitcoin.

Kindly,
        MZ

As long as it's not an exchange address, yes.

M

[mdude77]

I was thinking about the whole S2/S3 problem with p2pool.  Do we know if other ASICs have the same problem, they can't respond quick enough to the 30s or less "drop everything you're doing and start over" requests?  Assuming so, is this a possible solution?

The basic requirement is changing p2pool to stop having to send those job restart requests every 30 seconds.  We know if we change the share time to more than 30s, share difficulty increases accordingly.

What if p2pool only sends the job restart request when a new Bitcoin block is found, roughly every 10 minutes?  

For that to work, it'd require a fundamental change in the p2pool "alt" share chain.

Instead of it being a chain, make a sequence of rings.  Each ring is composed of shares submitted by miners built upon the last Bitcoin block and the payout data of shares in the p2pool altchain.  They are _not_ built upon the last share submitted.

This has a few immediate consequences:

1 - When a p2pool block is found, payment is based entirely upon shares submitted up to the last Bitcoin block.  Every share submitted after that gets bundled into the next "ring".  That means payments are roughly 10 mins behind your shares, which I feel is of no consequence.
2 - Share orphans will drop significantly, since each share is no longer attempting to build upon the prior share, but the prior job p2pool submitted.  Again, that job is based upon the last Bitcoin block + the payout data of the p2pool altchain up to that last Bitcoin block.
3 - Share verification has to change, as it's no longer a chain, but a sequence of rings connected by Bitcoin blocks.  I'm not seeing how this is a show stopper, as each node should be able to verify the share's legitimacy and confirm the current job we're working on is legit.
4 - Job restarts are submitted on average once every 10 minutes, according the Bitcoin chain.
5 - We're talking a fork of the p2pool chain.
6 - Alt chain share size can not be arbitrarily set, presumably lower to solve the "low hash rate miner eligibility" problem.  However the lower it gets, the bigger the rings get for each round, which means a longer share chain.  However we could keep less than 3 days worth to compensate if need be.  (I would argue it'd be better to lose some private nodes that don't have the bandwidth and get more miners than it would be to have more smaller nodes but a less secure "chain".)  Lastly, it could be based on the number of shares submitted per 10 minutes, so the difficulty could still adjust each round if need be.

Thoughts?

M

EDIT: Added point 6.

[windpath]

3 - Share verification has to change, as it's no longer a chain, but a sequence of rings connected by Bitcoin blocks.  I'm not seeing how this is a show stopper, as each node should be able to verify the share's legitimacy and confirm the current job we're working on is legit.

This is the kicker, as it would require an entire new trustless proof-of-work system... Right now each p2pool share is built on the existing shares in the chain, and includes the previous shares payouts to each miner. Without a blockchain-like system the proof of work for p2pool (and trustless  payouts for previous shares to miners) breaks.

[rav3n_pl]

Entire idea of p2pool share chain is, that noone can forge hash power and everyone can check who is mining, like in bitcoin block chain.
I not see, HOW you want to collect and VERIFY data collected by miners across entire POOL?
Only way I see, is kind of MOPS node, which is NOT sending LP/WR signals every share and collecting shares on share diff 256 or something.
This way NODE payout can be split between node miners, but because no fast lp/wr signals node efficiency will be compromised.

[windpath]

Awesome work windpath
 

Can I ask,  what is the end game for hosting a 0% p2pool node?  Obviously it costs you money.

One is to support a decentralized bitcoin I am sure, but what else are your goals?

Thanks.

My short term goals are pretty similar to many others here:

1. Grow the p2pool network; first through the addition of new nodes run by active miners, and second by providing access to reliable fast nodes for those without the time or inclination to set up their own.

2. Complete transparency; p2pool is in the unique position to be the first completely transparent pool. The data is all there, its just a matter of collecting, storing and presenting it to users.

3. Hardware compatibility; Work towards getting as much existing and new hardware to play well with the pool. New generations of HW are particularly important, as without them the pool will eventually dwindle.

4. Solve the variance/small miner challenges facing the pool so that it can grow and scale while remaining an attractive option to all.

To be honest, right now the "end game" is so far in the future its not even really a concern... At some point, if both Coin Cadence and p2pool are running strong, I do plan to implement some sort of revenue stream to support the operation of my node(s), and maybe even make a small profit, but for now and the foreseeable future working towards the challenges above takes priority, and I'm happy to host my node(s) on my own dime...

[mdude77]

3 - Share verification has to change, as it's no longer a chain, but a sequence of rings connected by Bitcoin blocks.  I'm not seeing how this is a show stopper, as each node should be able to verify the share's legitimacy and confirm the current job we're working on is legit.

This is the kicker, as it would require an entire new trustless proof-of-work system... Right now each p2pool share is built on the existing shares in the chain, and includes the previous shares payouts to each miner. Without a blockchain-like system the proof of work for p2pool (and trustless  payouts for previous shares to miners) breaks.

I'm not seeing how it's trustless.  Each node can verify the blockchain, and how it was derived.  Each share can be verified as being a legitimate share for that round of work, and each round of work can be verified as coming from the prior round + shares.  Am I missing something?

M

[mdude77]

Entire idea of p2pool share chain is, that noone can forge hash power and everyone can check who is mining, like in bitcoin block chain.
I not see, HOW you want to collect and VERIFY data collected by miners across entire POOL?
Only way I see, is kind of MOPS node, which is NOT sending LP/WR signals every share and collecting shares on share diff 256 or something.
This way NODE payout can be split between node miners, but because no fast lp/wr signals node efficiency will be compromised.

Shares would still be distributed and verified.  Those that are invalid would be rejected, as they are today.  The difference is, instead of each share being built upon the prior one, each share is built upon the prior work round, and the prior work round is based upon the prior Bitcoin block + shares in chain prior to that block.

I wasn't looking to compromise the trust no one principle.

M