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

[h3m96]

I have got 2 Antminer S1's now and other stuff, so I have 510 GH/s power.   When my new miner gets here in the next 2 days, another 60 GH/s BFL and another Antminer S1, I will have about 770 GH/s full power.     Right now, I have 26 GH/s on p2pool and the remaining 500 GH on Slush. 

I was planning on putting the new Antminer I'm getting soon on p2pool and the 60 somewhere else.  Do you think I should divide them up differently?   

[1713519752]

1713519752

[1713519752]

1713519752

[1713519752]

1713519752

[1713519752]

1713519752

[1713519752]

1713519752

[1713519752]

1713519752

[smooth]

I was planning on putting the new Antminer I'm getting soon on p2pool and the 60 somewhere else.  Do you think I should divide them up differently?   

I can't tell you how to set your priorities of mining. My suggestion was just a way to reduce variance while still helping p2pool and the decentralization of the overall bitcoin network. If you want more steady payouts, put more on the bigger pools, if you want to help decentralization, put more on the smaller pools (and especially p2pool). But either way you can still accomplish both goals to a large extent.

[h3m96]

Honestly, I'd much rather help decentralization. 

[-ck]

Honestly, I'd much rather help decentralization. 

Easy then, throw everything at p2pool.

[h3m96]

Thanks!  How do I apply this kernel patch on your site, the linux 3.13?   I'm on Ubuntu 13 and I have this kernel:  3.2.0-59-generic-pae

Would that patch even work on my system?  Just curious, I just saw your site and thought I'd ask.   

[irrational]

So, I'm in the process of writing on Stratum client, and I'm getting some odd results from p2pool.

In the p2pool log, I'm seeing a ton of these:

2014-04-14 21:10:16.531268 Worker 12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF submitted share with hash > target:
2014-04-14 21:10:16.531393     Hash:   93b4405c1ef4a1104a9a26bf30cbce5034847d7a6d5cb6babc8792326ef6b0ce
2014-04-14 21:10:16.531472     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

I've tried reading through p2pool's source, but Python isn't my thing and the code doesn't appear well structured IMHO. So, it was hard for me to tell if "target" referred to:

a) A Bitcoin block target - unlikely
b) A p2pool share - my first thought
or
c) A difficulty 1 (or x) share - my fear

My first guess was B, as my transactions with P2Pool have looked like this:

{"params":["12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF","142929675283333299491430029355155482840","39000000","534c9506","d9d444d8"],"id":43,"method":"mining.submit"}

And P2Pool's response:

{"id":43,"error":null,"result":true}

So, it appears to be giving me a thumbs up, and my miner is happily mining away. Unfortunately if I visit http://localhost:9332 in my browser, it reports my local rate as 0. Thusly why I'm starting to fear C 

Any thoughts? I hope I made sense of that all.

[h3m96]

When I look at my log, I don't see anything like that.  I have, however, seen that fffffffffffff thing, when my Win8 computer for some reason goes offline.  I was mining wireless on it the last 2 days with cgminer and I'm not sure if I had the right drivers installed via Zadig.    If you have 0 hashrate, maybe you're not connected? Just a thought

[kano]

...
I just want a steady income ($1736/mo) to live on!
...

Which requires ... every 2016 blocks ... to increase your hash rate by the % the difficulty goes up.

Which requires ... every 2016 blocks ... to increase your electricity usage ... and thus increase the $ amount to cover it.

Which requires ... every day you convert BTC to $ ... to increase or decrease your hash rate by the change in the BTC <-> $ exchange rate.

But in reality, the issue is that you seem to have stated, is that you are only mining BTC to cash it out.
You have no care or consideration for what BTC represents, how it can be used to the advantage of BTC and what it may be worth in the future.
So ... I don't really see the point of caring what pool you mine on ...

[h3m96]

I have no care/consideration for what Bitcoin represents?  HUH??

You are a cgminer developer?   Please explain your ethical position to me.  I do not understand why you think I am abusing the Bitcoin network by simply mining on it.     

[h3m96]

Kano:  if you know ckolivas and you developed cgminer together, I'm assuming I don't know, but why was he not saying those things to me? 

What would you do differently if you were me?  That'll help me understand better.

[KyrosKrane]

Then they do pseudo experiments ignoring all the things I said above and show a better payout at some random other pool for that day and they're lost for good.

While you're technically correct, I would contend that to the average user, his "pseudo experiment" is a pretty good indicator of his profitability, delta his very short term luck.  I understand the math behind this, and why this is wrong in the greater scheme of things. I know about variance, and about short term spikes (or dips!) in luck, and all the good stuff about p2pool and why it's better for a decentralized network than other alternatives.

But here's the thing - all of that is irrelevant to Joe Blow Miner. I have X GH/s of mining power.  If I point them at p2pool, or at GHash.io, or at Slush's, or at any other pool, I'm still "supporting the network", so long as I'm cautious about fraudulent pools or ones approaching 40% or more of the network.  The differentiating factors then become ease of use and profitability.

I'm pretty sure we can all agree that running your own p2pool node is a lot more complex than just typing in a URL into your miner. Using someone else's node is the same as any other pool.

So let's look at profitability. The common refrain when users complain about uneven payouts from p2pool is that it will all average out over the long term. This is not a useful answer to a user who's burning electricity for (what seems like) no gain. An answer of "wait a few months" is not going to sway the user. We need a better answer.

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

And that doesn't even take into account the reduced pool hashrate that will result from a three-month dry spell.

So the short answer is the same it's always been: we need to find a way to make p2pool more attractive to users. That in turn will increase our chance of finding a block in a reasonable time, reduce the variance, and increase profitability for everyone. And yes, I realize the catch-22 inherent in what I just wrote.

[smooth]

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

Sigh. I'm getting so tired of arguing with math fallacies. So I won't.

[nreal]

Much more fun solomining Terracoin than Btc with p2pool - up to 5 blocks/day with 120GH 

Im in a hurry.

[KyrosKrane]

The thing is, while variance may average out over the long term, that only matters if difficulty remains the same.  If you think that I'm wrong, let me offer you a scenario. Hypothetically, let's say that based on current pool hashrate and network difficulty, we can expect one block per day. I'll offer you a choice. You can get three months of double the expected block success (two blocks per day initially), followed by three months of zero payouts. OR, you can get three months of zero payouts, followed by three months of double the expected success rate.  

The naive answer is that both will average out to the same thing - and that answer is correct so long as the pool maintains the same hashrate and block difficulty throughout the six months. In reality, even if we hold the pool hashrate constant over six months, your total payouts with the two options will be radically different due to the increasing difficulty rate. The double payouts followed by a dry spell will earn much more than a dry spell followed by double payouts, simply because you're getting paid when difficulty is lower - thus more blocks are found during a given time period.

Sigh. I'm getting so tired of arguing with math fallacies. So I won't.

My statement is that while things may average out over the long term, I don't live or mine in the long term - only in the short term. If in the short term I get better results on another pool then I'm more inclined to stay with the other pool.  It's exactly the same logic as saying that if I go to Las Vegas casino A and lose, then go to casino B, play the same games, and win, I'm more inclined to play at casino B the next day. Long term, on average, most players will lose at both casinos, which is why the casino business can be so profitable - but individuals can and do win big in the short term. It's pure gambler's fallacy, but it's the way many people think - both in terms of casinos and in terms of pools.

Here's the math basis I used to come to this conclusion I stated in the quote above. For simplicity, I made the following assumptions:

• Difficulty adjusts every 10 days exactly, and each increase is exactly 5%.
• All months have 30 days.
• A starting difficulty of six billion (expressed in millions below, so 6000 = 6000MM).
• Both overall pool hash rate and your share of that hash rate remain constant (which means your p2pool shares per period of time is also assumed to be constant).
• The pool always find blocks at the expected rate.

Here's the part I'm not 100% on. I'm assuming that if the difficulty exactly doubles, then your chance of finding a block is exactly halved.  I suspect this isn't correct, but regardless, it's certain that as difficulty increases, the chance of finding a block decreases. So while the block probability numbers below may be slightly off, the overall trend would be the same.

Here's what the block-finding probabilities would look like (note that the table lists number of blocks found per 10-day period, not amount of BTC earned).

Period #	Starting month	Starting day	Starting difficulty	Chance of block/day	Blocks found
1	1	1	6,000	1.000	10.000
2	1	11	6,300	0.952	9.524
3	1	21	6,615	0.907	9.070
4	2	1	6,946	0.864	8.638
5	2	11	7,293	0.823	8.227
6	2	21	7,658	0.784	7.835
7	3	1	8,041	0.746	7.462
8	3	11	8,443	0.711	7.107
9	3	21	8,865	0.677	6.768
10	4	1	9,308	0.645	6.446
11	4	11	9,773	0.614	6.139
12	4	21	10,262	0.585	5.847
13	5	1	10,775	0.557	5.568
14	5	11	11,314	0.530	5.303
15	5	21	11,880	0.505	5.051
16	6	1	12,474	0.481	4.810
17	6	11	13,097	0.458	4.581
18	6	21	13,752	0.436	4.363

So, how does that look like in terms of blocks?

Option 1: double blocks for first three months, zero for next three months. Total blocks found: about 150 (with rounding).
Option 2: zero blocks for first three months, double for next three months. Total blocks found: about 96 (with rounding).

Option 0: no scenario, just straight mining for six months: Total blocks found: about 123.

Which would you pick? Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.  If I buy mining gear with a useful lifespan of a few months to a year, it very much matters to me which option I pick.

[roy7]

Which would you pick?

The point you are seemingly missing or ignoring is that the odds of either great luck or terrible luck happening are the same, and you don't know which will happen ahead of time. You don't get to pick.

Yes, larger pools provide smaller variance. Everyone knows that.

Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.

What the heck, I'll play along. How do I choose the pool which is about to have 3 months of finding blocks at twice the normal rate? Yes I'll choose that option too. Will you share which pool it is going to be?

[jonnybravo0311]

Quick question.  What happens when the expected time to block exceeds the rolling window of shares counted for payout?

Yes, I understand that you *might* have a string of luck where you find more blocks than expected, and you also *might* have a string of luck where you might find fewer blocks than expected.  However, we are dealing with an expected time to block, because that's what the "average" should work out to be given enough time.

Currently, it's a 3 day window of shares counted for payout, correct?  If that's the case, then our average time to block (given the latest stats I'm looking at in my local p2pool node and those on p2pool.info) with ~130TH/s is ~2.3 days.  So, with that average, we're good because time to block falls within the payout window.

If the hash rate is such, or the difficulty is such, or whatever, where the expected time to block becomes 4 days, 5 days, longer... doesn't that equate to "wasted" work mining because there are days gone by without being counted?

Please educate me oh Gurus of Mining Knowledge!

[jonnybravo0311]

On a different topic, but still very much related to educating me...

What is the recommended setup when you've got multiple miners pointing to a local p2pool node?

Let's first describe the hardware:

Box running local p2pool node and Bitcoin-Qt.  P2Pool pays out to wallet address other than the one running locally.  Since it's a local node, there are no fees (seems a bit silly to charge myself)
2 Antminer S1
1 Raspberry Pi controlling 5 Antminer U2 USB sticks

Options:

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.

If I go with option 3, does the p2pool node software dole out appropriate difficulty to each miner?  Here, the 2 S1s at 200GH/s each should get higher difficulty than the 5 U2 sticks with a total of 8GH/s, right?  I realize that it really doesn't make much difference in the long run since the difficulty is purely for "lying" to the miner and getting better approximations of hash rate by allowing the miner to solve less difficult shares, right?

Again, thanks for the inputs!

[KyrosKrane]

Which would you pick?

The point you are seemingly missing or ignoring is that the odds of either great luck or terrible luck happening are the same, and you don't know which will happen ahead of time. You don't get to pick.

Yes, larger pools provide smaller variance. Everyone knows that.

Given that your BTC payout per block is constant (as per our assumptions), I'd much rather have the first option.

What the heck, I'll play along. How do I choose the pool which is about to have 3 months of finding blocks at twice the normal rate? Yes I'll choose that option too. Will you share which pool it is going to be?

I'm not missing it at all; in fact, that's the point I was trying to make. I even highlighted it with my example of the gambler's fallacy! What I was saying is that while you can't predict when a good streak will come, you have to judge for yourself whether you can ride out the cold streaks. For a machine with a useful life of months, an extended cold streak like what we're seeing now means a significant loss. Many users will decide they'd rather have smaller but more consistent payouts from a traditional pool, rather than larger but inconsistent payouts from p2pool. If we want p2pool to thrive, we have to find a way to counter that.

[KyrosKrane]

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.

I actually had to make a very similar decision recently. What I learned is that if you don't set an address (and instead use a generic label like "Antminer") for each miner, then all the shares earned will default to the payout address you've set for your pool.  That way, you can track each device individually in your local p2pool node's stats, but still get the benefit of a combined payout.  If you use the -a option on the command line, you can specify any payout address, even one that isn't part of the local bitcoin node's wallet.

If you prefer, you can set a specific payout address for each device, and track the earnings that way, but with your RPi, you won't get shares very often.  That will lead to long stretches of no shares.  Also your payouts will be more fragmented, which means when it comes time to spend them, you'll have to pay slightly higher transaction fees.

As to your options, you could do #1, but I personally went with the "labels" option I mentioned. #2 is more or less identical to #1; it's just up to you where you define the address (on each miner, or on p2pool's command line). #3 is also permissible, but has the downsides I mentioned.

[jonnybravo0311]

1) Have all miners payout to a single address by starting each with -u MYPAYOUTADDRESS, where MYPAYOUTADDRESS is the same as the address the p2pool node pays.
2) Have all miners payout to a single address as in option 1; however, that address is not the same as the p2poool node payout address
3) Have each miner payout to a different address, independent of the node's payout address.
4) Something I haven't thought of?

If my understanding is correct, the only time the p2pool node would payout to it's default address is if I'm collecting fees.  If I want to see payouts on the "Payout if a block were found now", I would have to set my miners to pay to the node's payout address as well.

I actually had to make a very similar decision recently. What I learned is that if you don't set an address (and instead use a generic label like "Antminer") for each miner, then all the shares earned will default to the payout address you've set for your pool.  That way, you can track each device individually in your local p2pool node's stats, but still get the benefit of a combined payout.  If you use the -a option on the command line, you can specify any payout address, even one that isn't part of the local bitcoin node's wallet.

If you prefer, you can set a specific payout address for each device, and track the earnings that way, but with your RPi, you won't get shares very often.  That will lead to long stretches of no shares.  Also your payouts will be more fragmented, which means when it comes time to spend them, you'll have to pay slightly higher transaction fees.

As to your options, you could do #1, but I personally went with the "labels" option I mentioned. #2 is more or less identical to #1; it's just up to you where you define the address (on each miner, or on p2pool's command line). #3 is also permissible, but has the downsides I mentioned.

Great point.  That would be option 4 - one I didn't think of  Just start the miners up with usernames like "S1_1", "S1_2", "rPi" and they will default payout to the node's wallet.  I'll restart them that way so I can track each miner's performance, but get the benefits of combined payouts (and like you stated, smaller fees because the payouts would be larger).

Thanks for the tip!