Bitcoin Forum
December 11, 2016, 10:13:28 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 [102] 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035661 times)
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
April 21, 2012, 07:10:06 PM
 #2021

Let's talk numbers and theory. My theory is that orphans (p2pool's stale shares or Bitcoin's orphan blocks) are caused by latencies between the miner, p2pool node, p2pool network for p2pool stale shares and miner, p2pool node, bitcoind and the Bitcoin P2P network for orphan blocks.

Furthermore, as I understand things, the amount of stale shares should be proportional to the miner/p2pool node/p2pool network latencies. For example, if on average a share comes every 10 seconds and on average the latency is around 100ms for all miners, we should have 1% of stale shares (there's a ~1 in 100 chances that another valid share can be found by a node until it knows the share and inform miners to work on it). We have around 8% stale shares right now, so I estimate the latencies between miners on the p2pool network to be around 800ms (seems high at first but isn't too bad when you consider that the p2pool network should cover the whole planet and there are at least 3 components involved in latencies : miner, p2pool node and bitcoind process).

If bitcoind and the Bitcoin network were roughly as efficient as p2pool, the amount of orphans should be around 800ms/10min (in fact around 1/60 the proportion of p2pool's stale share given the target interval difference). Currently it should be 0.133% instead of 1.8%. Although 1.8% can't impact us much (our luck is around 90%, so if there's a problem, it isn't caused by orphan blocks), it's rather high when compared to what p2pool can achieve with a 10 seconds target interval instead of a 10 minutes. Either bitcoind isn't optimized or the size of the Bitcoin network compared to p2pool adds noticeable latencies.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
1481451208
Hero Member
*
Offline Offline

Posts: 1481451208

View Profile Personal Message (Offline)

Ignore
1481451208
Reply with quote  #2

1481451208
Report to moderator
1481451208
Hero Member
*
Offline Offline

Posts: 1481451208

View Profile Personal Message (Offline)

Ignore
1481451208
Reply with quote  #2

1481451208
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
twmz
Hero Member
*****
Offline Offline

Activity: 737



View Profile
April 21, 2012, 08:10:09 PM
 #2022

Poor connection to the bitcoin network could result in higher BLOCK orphans but p2pool has <1% block orphan rate which is similar to other pools.

We have 331 total blocks and 6 of them orphaned.  That's a rate of 1.8%.

The note about orphans on http://p2pool.info/ suggests that the real number is higher than that too. A pool can count every one of their orphans but we can't. Would be nice to know for sure one way or another if the block orphans are a big factor or not. (The share orphans are a non-issue)

Note, the orphans that are known (the 6 on p2pool.info) are already accounted for in the luck calculations (i.e. luck is not reduced by known orphans).  The only think that could, in theory, be making the luck look lower than it should is unknown orphans, and I don't think there are many of them.  While the statement I made on p2pool.info is technically accurate, I do scan blockchain.info regularly looking for orphaned blocks and it does a pretty solid job of knowing about all orphaned blocks because it connects to 3000+ bitcoin nodes.

Was I helpful?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
April 21, 2012, 09:43:41 PM
 #2023


Might be worth running the calculation to see how much hashpower it would cost a large competitor (pool) to run a p2pool node and refrain from sending in blocks. It would need to do this only at a level that makes p2pools persistent "bad luck" slightly worse than paying fees at pools to be effective.

Back of envelope says 5-10% has gone missing somewhere, assuming it is not all bad luck, so say around 30 GHash/s? Would it be worth it to "them"?

Ente
Legendary
*
Offline Offline

Activity: 1834



View Profile
April 22, 2012, 06:16:05 AM
 #2024


Might be worth running the calculation to see how much hashpower it would cost a large competitor (pool) to run a p2pool node and refrain from sending in blocks. It would need to do this only at a level that makes p2pools persistent "bad luck" slightly worse than paying fees at pools to be effective.

Back of envelope says 5-10% has gone missing somewhere, assuming it is not all bad luck, so say around 30 GHash/s? Would it be worth it to "them"?

"Worth"? That assumes some gain by doing that. To drive away p2pool-users? It would be easier by a magnitude to use those 30Gh/s to "normally" mine for profit, and attack a regular centralized pool with DDOS. That would drive off their users to some degree, maybe attracting some of them for his own pool.

All data is there already anyway. We see which nodes exist, which nodes contribute how many shares (to add to the p2pool net hashpower) and which nodes do or do not find bitcoin blocks (to reduce the luck). If someone wants, he should be able to dig through the stats to verify/falsify this. Even if those 30Gh/s were on dozens of individual nodes, they probably come from the same IP. Even if not, with 30Gh/s you should be able to find anything, any clue.

You see, even with this "bad luck", people are sticking to p2pool, as can be seen in the stats. Not because p2pool is necessarily paying out better than all other pools at any time, but because p2pool is superior and healthier for the whole bitcoin universe.

But yes. I believe p2pool has a problem which may have stayed unidentified yet. The "hashing power reflected by hashes" and "hashing power reflected by blocks" are two fairly straight lines, but clearly diverging. Its not two overlapping lines, its not one line being crossed by the other all the time.
Connectivity seems to be one problem for the individual miner. Not for the global p2pool efficiency though.

Ente
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
April 22, 2012, 07:48:11 AM
 #2025


No need to get all uppity, I'm just trying to eliminate some possibilities to get to the bottom of the pool's poor performance ... it may be bad luck but it is looking like more than that the longer it continues.

ChanceCoats123
Hero Member
*****
Offline Offline

Activity: 680



View Profile
April 22, 2012, 08:07:25 AM
 #2026

Not to mention people are staying with p2pool because they are lazy... (this guy). All jokes aside, it's easy to stay with the familiar. Smiley
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
April 22, 2012, 10:58:03 AM
 #2027

...
You see, even with this "bad luck", people are sticking to p2pool, as can be seen in the stats. Not because p2pool is necessarily paying out better than all other pools at any time, but because p2pool is superior and healthier for the whole bitcoin universe.
...
Um - you wanna explain that one?
I'd like to see your opinion of how p2pool would cope with DeepBit's hash rate ...

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Syke
Legendary
*
Offline Offline

Activity: 2100


View Profile
April 22, 2012, 02:56:46 PM
 #2028

I'd like to see your opinion of how p2pool would cope with DeepBit's hash rate ...

Average daily payout would be the same. Time to find shares would go up, and blocks found per day would also go up.

A slow 1 gh/s miner on p2pool gets a share on average every 45 minutes while p2pool finds a block every 4 hrs. Deepbit is 10 times the size of p2pool, so the 1 gh/s miner would get a share every 7.5 hrs and p2pool would find a block every 24 minutes. Large scale p2pool miners can adjust their share-rate, which will make shares easier for slow miners.

Buy & Hold
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 22, 2012, 11:43:23 PM
 #2029

I'd like to see your opinion of how p2pool would cope with DeepBit's hash rate ...

Average daily payout would be the same. Time to find shares would go up, and blocks found per day would also go up.

A slow 1 gh/s miner on p2pool gets a share on average every 45 minutes while p2pool finds a block every 4 hrs. Deepbit is 10 times the size of p2pool, so the 1 gh/s miner would get a share every 7.5 hrs and p2pool would find a block every 24 minutes. Large scale p2pool miners can adjust their share-rate, which will make shares easier for slow miners.
Sure, if p2pool could scale infinitely. But there are a few things that would have to be resolved before we could get that kind of scalability.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
April 22, 2012, 11:54:06 PM
 #2030

Sure, if p2pool could scale infinitely. But there are a few things that would have to be resolved before we could get that kind of scalability.

Huh? P2Pool would continue to work if one DeepBit-equivalent of miners joined. Variance would just go up. P2Pool adjusts the share difficulty to keep traffic/CPU usage constant.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 23, 2012, 12:01:03 AM
 #2031

Sure, if p2pool could scale infinitely. But there are a few things that would have to be resolved before we could get that kind of scalability.

Huh? P2Pool would continue to work if one DeepBit-equivalent of miners joined. Variance would just go up. P2Pool adjusts the share difficulty to keep traffic/CPU usage constant.
Right, I should clarify: yes p2pool itself should be able to handle it, but I doubt many miners would remain when the difficulty is so high that they may or may not get in a share in each block. It would have a negative feedback kind of effect, I would think.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Syke
Legendary
*
Offline Offline

Activity: 2100


View Profile
April 23, 2012, 12:16:08 AM
 #2032

Right, I should clarify: yes p2pool itself should be able to handle it, but I doubt many miners would remain when the difficulty is so high that they may or may not get in a share in each block. It would have a negative feedback kind of effect, I would think.

Who cares if you get a share in every block? You'll still get roughly the same number of payouts each day, even at a deepbit-size level.

Now if p2pool was 10 times the size of deepbit, then the difficulty would be so high that lots of small miners would not get daily payouts. That would be a problem. I look forward to p2pool growing so large that becomes a problem.

Buy & Hold
ChanceCoats123
Hero Member
*****
Offline Offline

Activity: 680



View Profile
April 23, 2012, 01:31:51 AM
 #2033

But then you can have the larger (say 5ghash/sec +) miners use a > 300 share difficulty so the smaller miners can remain semi-profitable and use a lower difficulty. Since the larger miners have "lower" variance as-is, a slightly higher share difficulty will have little to no impact on their payouts, but greatly help the smaller guys.
TheHarbinger
Sr. Member
****
Offline Offline

Activity: 378


Why is it so damn hot in here?


View Profile
April 23, 2012, 02:00:52 AM
 #2034

Hopefully, auto-adjusting difficulty based on hashrate is something that will be coming in a future version.

12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
Ente
Legendary
*
Offline Offline

Activity: 1834



View Profile
April 23, 2012, 10:30:55 AM
 #2035

Hopefully, auto-adjusting difficulty based on hashrate is something that will be coming in a future version.

That got me thinking.
Yes, this seems to be a good idea!
How to adjust the individual share difficulty?

- To have it similar to now (one share each 10 sec), each node would poll the number of nodes and the p2pool hashrate. If the individual hashrate is "high" compared to the average node's hashrate, make the local share-difficulty higher.
Quite complicated, maybe unstable, and all in all not too elegant, in my view..

- Drop the "one share every 10 sec" altogether. Make every node find one share, say, every 10 mins. Big miners will have a high local difficulty, small miners a low one. Depending on the amount of nodes, the sharechain would grow faster or slower than now. With those 10 mins per local share and approx 200 users at the moment, there would be a new share every 3 secs. This probably is too short, so we may make it "node, find a share every 30 mins!" for an approx sharechain-growth of one share every 10 secs.

This would not scale too far neither. But it would be a lot easier and with less drastic changes than the other, older proposals (sub-p2pool, multi-p2pool etc). So it might be a bridge-technology, as we say here.

Ente
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 23, 2012, 12:28:13 PM
 #2036

The issue with those proposals is that without an enforced minimum difficulty cheating to reduce variance becomes trivial.  You create a tragedy of the commons situation where users unhappy with their share variance simply "cheat" and submit lower variance shares.  The network "speeds up" and avg LP interval falls from 10sec to 7sec or 5 sec.

If anything 10 sec is too short.  It is right at the inflection point.  Intervals shorter than 10s will result in significantly higher oprhan rates.  5s won't be double the 10s rate it will be more like 4x (so ~40% global stale rate). It is absolutely critical that the LP interval remain >=10s.
VoluntaryMan
Newbie
*
Offline Offline

Activity: 29



View Profile WWW
April 23, 2012, 12:37:35 PM
 #2037

My estimated payout has gone down by about 50% for the past few days... Anyone have any ideas as to why this may be?
My hashrate has stayed about the same 371Mhash/s.

Want to thank me for a post? Send some BTC my way:
1C3wPaCGAYh9RBhMwpWMkmj1yJJP3U6XmP
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 23, 2012, 12:38:43 PM
 #2038

My estimated payout has gone down by about 50% for the past few days... Anyone have any ideas as to why this may be?
My hashrate has stayed about the same 371Mhash/s.
Take a look at avg block times for the last 5 blocks. Sad

If we find 50% of the block (compared to expected) your payout will be 50% of expected.
If we find 200% of the blocks (compared to expected) your payout will be 200% of expected.
VoluntaryMan
Newbie
*
Offline Offline

Activity: 29



View Profile WWW
April 23, 2012, 01:42:36 PM
 #2039

My estimated payout has gone down by about 50% for the past few days... Anyone have any ideas as to why this may be?
My hashrate has stayed about the same 371Mhash/s.
Take a look at avg block times for the last 5 blocks. Sad

If we find 50% of the block (compared to expected) your payout will be 50% of expected.
If we find 200% of the blocks (compared to expected) your payout will be 200% of expected.
Ah, so just bad luck at the moment?
This is what I thought.

Want to thank me for a post? Send some BTC my way:
1C3wPaCGAYh9RBhMwpWMkmj1yJJP3U6XmP
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
April 23, 2012, 02:26:01 PM
 #2040

My estimated payout has gone down by about 50% for the past few days... Anyone have any ideas as to why this may be?
My hashrate has stayed about the same 371Mhash/s.
Take a look at avg block times for the last 5 blocks. Sad

If we find 50% of the block (compared to expected) your payout will be 50% of expected.
If we find 200% of the blocks (compared to expected) your payout will be 200% of expected.
Ah, so just bad luck at the moment?
This is what I thought.

Yeah but a pretty brutally bad run of it.
Pages: « 1 ... 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 [102] 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!