Author

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

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
I have no care/consideration for what Bitcoin represents?  HUH?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.     
Well, oddly enough, if you ignore part of what I said, you will indeed not understand what I said ...
newbie
Activity: 43
Merit: 0
Don't use the mining proxy? iirc p2pool works fine with getwork.
ASICMiner Block Erupter Cube directed to p2pool has only about 60% efficiency
and p2pool not show hashrate fo it insted console msg:

I believe others have said cubes don't work well with p2pool.  But hey, 60% is better than 0% with the proxy. Smiley

Seriously, I suggest another pool with a cube.

cubes work well with proxy - 97-98% efficiency...
will be fine that proxy work with p2pool...
legendary
Activity: 1540
Merit: 1001
Don't use the mining proxy? iirc p2pool works fine with getwork.
ASICMiner Block Erupter Cube directed to p2pool has only about 60% efficiency
and p2pool not show hashrate fo it insted console msg:

I believe others have said cubes don't work well with p2pool.  But hey, 60% is better than 0% with the proxy. Smiley

Seriously, I suggest another pool with a cube.

M
newbie
Activity: 43
Merit: 0
Don't use the mining proxy? iirc p2pool works fine with getwork.
ASICMiner Block Erupter Cube directed to p2pool has only about 60% efficiency
and p2pool not show hashrate fo it insted console msg:
Code:
2014-04-16 12:28:24.499000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:24.795000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:24.795000     Hash:   b06b586f4dac49697137d0d941e4bb5460f6b340cd1b2bc02236bf79cdcf8ad
2014-04-16 12:28:24.795000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:24.811000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:24.811000     Hash:   fbc6c59bd5586e439ea88260933111aefff5a2d5c8916302453781ce60c494ed
2014-04-16 12:28:24.811000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:24.826000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:24.826000     Hash:   4d1503faebd95b9e174da6e32146fbc131767282eb88d4b2c8edf6e6fd17ed47
2014-04-16 12:28:24.826000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.060000 P2Pool: 17688 shares in chain (14732 verified/17692 total) Peers: 6 (0 incoming)
2014-04-16 12:28:25.060000  Local: 0H/s in last 10.0 minutes Local dead on arrival: ??? Expected time to share: ???
2014-04-16 12:28:25.060000  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2014-04-16 12:28:25.060000  Pool: 165TH/s Stale rate: 13.0% Expected time to block: 1.8 days
2014-04-16 12:28:25.232000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.232000     Hash:   63311e01ab25caf7eb4760d5557ec77eaf7cfe037568d7f6abd23359d31f9a03
2014-04-16 12:28:25.232000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.248000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.248000     Hash:   e403b813ac18c496bdb9e7c98141944ddf0454abd39c1a38189823b3e8fcdcfb
2014-04-16 12:28:25.248000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.263000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.263000     Hash:   3987e9f12da6fbf7dd74b871f6e3994317da901e4de3366cd673915f981043a6
2014-04-16 12:28:25.263000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.279000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.279000     Hash:   e004ab6b08d567116c9334d6c1cbafb92c00fccbab6f0407f705efd2765c99a7
2014-04-16 12:28:25.279000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.638000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.638000     Hash:   e89f94af0e8430c4ab61b98a03b4e95d09888a14389b1691ea8c8486b446d783
2014-04-16 12:28:25.638000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.669000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.669000     Hash:   78bb795c7ebdf9d232f8e7227c5a3f1b4db6a2f10e967baf51e6a1ff2412a202
2014-04-16 12:28:25.669000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.684000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.684000     Hash:   49ae678a407d942dfaa7247a88e4b602d6c61ba4a6d26ef82751073de15c67ad
2014-04-16 12:28:25.684000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:25.716000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:25.716000     Hash:   ad28087bd567f5c6616ce674d80d0f9fa2d71f472538eefc7a13105cdc85e9e6
2014-04-16 12:28:25.716000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:26.028000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:26.043000     Hash:   9af797c5688dfa2ff9e6739b4b57d457349eb21e02e2b54ae7f160ff766052d6
2014-04-16 12:28:26.043000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:26.059000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:26.059000     Hash:   cfa674770ea156cb8aa45f188d07a623fc2d57a94ccedbb7007086f7544055d9
2014-04-16 12:28:26.059000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:26.106000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:26.106000     Hash:   5647fe3176bbe09fb5adc9bad7a502f92806708cfd3b47475210cd6698051ec8
2014-04-16 12:28:26.106000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
2014-04-16 12:28:26.308000 Worker cube253 submitted share with hash > target:
2014-04-16 12:28:26.308000     Hash:   7147c9870bcb9967e40e588e86e2471035bd78dc89c3998a3b146d2adb24f6e8
2014-04-16 12:28:26.308000     Target: db24b5c57d9bb0000000000000000000000000000000000000000000
legendary
Activity: 1540
Merit: 1001
anyone found solution for incompatibility mining_proxy with p2pool?

Code:
C:\>mining_proxy -o 127.0.0.1 -p 9332 -gp 8330
2014-04-16 11:30:30,444 INFO proxy jobs. # C extension for midstate not available. Using default implementation instead.
2014-04-16 11:30:30,444 ERROR proxy mining_proxy.main # Stratum host/port autodetection failed
Traceback (most recent call last):
  File "mining_proxy.py", line 182, in main
AttributeError: 'module' object has no attribute '_parse'
2014-04-16 11:30:30,444 WARNING proxy mining_proxy.main # Stratum proxy version: 1.5.5
2014-04-16 11:30:30,460 WARNING proxy mining_proxy.test_update # Checking for updates...
2014-04-16 11:30:31,022 WARNING proxy mining_proxy.main # Trying to connect to Stratum pool at 127.0.0.1:9332
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
Failure: stratum.custom_exceptions.TransportException: SocketTransportClientFactory connection timed out
2014-04-16 11:31:09,132 INFO proxy mining_proxy.on_shutdown # Shutting down proxy...

Don't use the mining proxy? iirc p2pool works fine with getwork.

M
newbie
Activity: 43
Merit: 0
anyone found solution for incompatibility mining_proxy with p2pool?

Code:
C:\>mining_proxy -o 127.0.0.1 -p 9332 -gp 8330
2014-04-16 11:30:30,444 INFO proxy jobs. # C extension for midstate not available. Using default implementation instead.
2014-04-16 11:30:30,444 ERROR proxy mining_proxy.main # Stratum host/port autodetection failed
Traceback (most recent call last):
  File "mining_proxy.py", line 182, in main
AttributeError: 'module' object has no attribute '_parse'
2014-04-16 11:30:30,444 WARNING proxy mining_proxy.main # Stratum proxy version: 1.5.5
2014-04-16 11:30:30,460 WARNING proxy mining_proxy.test_update # Checking for updates...
2014-04-16 11:30:31,022 WARNING proxy mining_proxy.main # Trying to connect to Stratum pool at 127.0.0.1:9332
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
Failure: stratum.custom_exceptions.TransportException: SocketTransportClientFactory connection timed out
2014-04-16 11:31:09,132 INFO proxy mining_proxy.on_shutdown # Shutting down proxy...
hero member
Activity: 516
Merit: 643
Still confused as to why I'm getting a "result: true", despite p2pool claiming the hash doesn't meet difficulty 1 though.

P2Pool only returns "result: false" for stale work, not invalid work, the idea being that rejected/accepted shares represent some useful quantity and that P2Pool will complain loudly if something is actually wrong.
newbie
Activity: 56
Merit: 0
A difficulty 1 share.

That target is 2^(256-32)-1, the maximum possible target for most hardware (H=0).

That message is printed when a miner returns work that doesn't match the target it was sent, meaning that there's a bug or other problem.

EDIT: That returned work has a hash that isn't low at all. What mining hardware are you using?

Thank you very much for that info. That was my fear.

As for hardware, I'm using Antminer U2s. But, I don't think the hardware is sat fault. If I point my Ants (via Bfgminer) directly at p2pool, it works. I don't get those messages, and the p2pool stats page displays a local hash rate.

This problem arises when I first point my miners to a proxy I'm writing, and then the proxy talks to p2pool. The stratum communication looks identical to me:

Message to p2pool:
Quote
{"params":["12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF","226858380923200241282647501746235717849","08000000","534ddc22","b9609317"],"id":800,"method":"mining.submit"}

Response from p2pool:
Quote
{"id":800,"error":null,"result":true}

And then in p2pool's console output I see these:

Quote
2014-04-15 20:26:07.905276 Worker 12uCQa1rEBxQutWUkXE2AA6LnhfrAPJpgF submitted share with hash > target:
2014-04-15 20:26:07.905412     Hash:   ef95748110ef4e9612d216da2cb08d1de41e28b872d7761aaff7db538d1f084b
2014-04-15 20:26:07.905520     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

I'm still trying to debug what I've done wrong, but I figured stopping in here and double checking my understanding of p2pool's message was a good start.

Still confused as to why I'm getting a "result: true", despite p2pool claiming the hash doesn't meet difficulty 1 though.
hero member
Activity: 516
Merit: 643
In the p2pool log, I'm seeing a ton of these:

Quote
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

Surely somebody knows which it's referring to?

A difficulty 1 share.

That target is 2^(256-32)-1, the maximum possible target for most hardware (H=0).

That message is printed when a miner returns work that doesn't match the target it was sent, meaning that there's a bug or other problem.

EDIT: That returned work has a hash that isn't low at all. What mining hardware are you using?
newbie
Activity: 56
Merit: 0
In the p2pool log, I'm seeing a ton of these:

Quote
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

Surely somebody knows which it's referring to?
legendary
Activity: 2968
Merit: 1198
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?

No. Think of mining like flipping 40 coins and trying to get all heads. Getting a share when the pool doesn't get a block is like flipping 40 coins and getting say 38 or 39 heads. Close but no cigar. This is not wasted work, just a near miss. It feels like it because your brain plays tricks on you and you feel that because you almost accomplished the required task, you "should" be rewarded. But no, it doesn't work that way.

sr. member
Activity: 434
Merit: 250
Great point.  That would be option 4 - one I didn't think of Wink  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!

Yeah that's probably the best way to go. This way all pay is on same address (less dust issues) but you can still graph your miners separately. However you do have the issue that the miners will have a single pseudo share target of 1/sec. You can upgrade the vardiff algorithm with the auto-worker-diff patch, or set the pseudo target you want each miner to have manually using +DIFF after their name.
sr. member
Activity: 434
Merit: 250
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.

Yes the pool's address (you can specify it with -a) is only for fees or if a miner connects with an invalid payment address.

I wouldn't worry about the "payout if a block were found now" overly much and instead recommend you install the p2pool-node-status interface, or one of the other ones that are nice. Smiley

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?

By default the vardiff for share difficulty and pseudoshare difficulty per miner will be set based on the total local node speed. If you want to be sure you get plenty of pseudo shares from each of your devices with varying speeds for graphing purposes, you probably need to add the auto-worker-diff patch so you can have the vardiff provide pseudo share difficulties by miner connection or by payment address. There's also a patch I made called vardiffbyaddress which sets actual share difficulty targets per payment address, but that's only useful to a public node with numerous people mining. For your own node, the auto-worker-diff is all you'd need to better control the pseudo share targets to each of your devices.

If all you cared about was total pool hash rate graphs, by default the node will aim for about 1 pseudo share per second. But your S1s will do so many that your USB miners get pushed down to doing far less than that, making their graphs very spotty (if you are graphing each miner separately).
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
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 Wink  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!
sr. member
Activity: 295
Merit: 250
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.
sr. member
Activity: 295
Merit: 250
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.
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
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!
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
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! Smiley
sr. member
Activity: 434
Merit: 250
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?
sr. member
Activity: 295
Merit: 250
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 monthStarting dayStarting difficultyChance of block/dayBlocks found
1116,0001.00010.000
21116,3000.9529.524
31216,6150.9079.070
4216,9460.8648.638
52117,2930.8238.227
62217,6580.7847.835
7318,0410.7467.462
83118,4430.7117.107
93218,8650.6776.768
10419,3080.6456.446
114119,7730.6146.139
1242110,2620.5855.847
135110,7750.5575.568
1451111,3140.5305.303
1552111,8800.5055.051
166112,4740.4814.810
1761113,0970.4584.581
1862113,7520.4364.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.
Jump to: