Bitcoin Forum
December 06, 2016, 02:18:43 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 [231] 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2031587 times)
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 11, 2013, 01:49:57 PM
 #4601

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
1481033923
Hero Member
*
Offline Offline

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

1481033923
Report to moderator
1481033923
Hero Member
*
Offline Offline

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

1481033923
Report to moderator
1481033923
Hero Member
*
Offline Offline

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

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

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

1481033923
Report to moderator
1481033923
Hero Member
*
Offline Offline

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

1481033923
Report to moderator
1481033923
Hero Member
*
Offline Offline

Posts: 1481033923

View Profile Personal Message (Offline)

Ignore
1481033923
Reply with quote  #2

1481033923
Report to moderator
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 01:50:14 PM
 #4602

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.
seems fine

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 01:50:55 PM
 #4603

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.
then rephrase it, set the PPLNS number so its rougly 7 days Wink

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 11, 2013, 01:55:23 PM
 #4604

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.
then rephrase it, set the PPLNS number so its rougly 7 days Wink

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.



Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 01:57:37 PM
 #4605

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.
then rephrase it, set the PPLNS number so its rougly 7 days Wink

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.
increasing it to a longer N would also help little miners, if they get a share and there is no block found they get nothing and are pissed, i saw that already some times.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 11, 2013, 02:00:54 PM
 #4606

the PPLNS system should be changed to the last 7 days.

Also I think about increasing difficulty. Current share time avg. 10sec is generating 10-15% DOA/orphans. That's the main reason why people don't use p2pool - no point to do that when you see miner stats with 10% rejected rate and loosing money.
I am voting to increase share time to 30 or 60 seconds and PPLNS time to 7 days. This would decrease stale ratio and attract more miners.

This is why PPLNS should always be in terms of the last n shares, not time. Difficulty and pool hashrate do not have an effect on the score variance if there is no termporal term in the scoring function.
then rephrase it, set the PPLNS number so its rougly 7 days Wink

I know what you mean, and it would help in the short term. But id n was set to (for example) 2 x current Difficulty, then you'd never have to change it. The PPLNS shouldn't be any number of days.

What would happen if the pool's percentage of the hashrate increased significantly? You'd want to change the number of days back down in order to reduce the time it took to recieve payment.
increasing it to a longer N would also help little miners, if they get a share and there is no block found they get nothing and are pissed, i saw that already some times.

It might seem unfair, but on average it makes no difference. Smaller miners will experience variance more on this pool especially since the share difficulty is so high for them.

PPLNS set to shares rather than hours will result in reduced variance for all miners.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 02:03:45 PM
 #4607

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 11, 2013, 02:13:36 PM
 #4608

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

You mean set n to ~ 9 x Difficulty? (that's seven days shares at the moment)

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 02:30:46 PM
 #4609

yes but if the PPLNS N is changed that it is around 7 days (according to the diff rules of p2pool), then its not day nor time based.

You mean set n to ~ 9 x Difficulty? (that's seven days shares at the moment)
something like this yes, but we would have to test it first since it means holding a bigger sharechain -> more memory/traffic being used

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
March 11, 2013, 02:47:26 PM
 #4610

Not necessary bigger share chain, if we put higher diff and longer long pool share chain can be same length aka consume same memory.
Make it 5 days long and 50sec longpool. It will be the same like it is now. Diff of next share need to be calculated every share from last 10/20 shares.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
March 11, 2013, 02:55:18 PM
 #4611

Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 11, 2013, 03:12:11 PM
 #4612

Note that if you change the target time between share and don't change N in PPLNS you won't change variance at all (the difficulty will rise in the same proportions than the time covered by the PPLNS window) : you will only make payments increase slower when someone begins mining on P2Pool (which is not a big selling point) and decrease slower when it stops (better, but people want instant gratification not promises for the future).

If you make N bigger, variance in mining rewards won't be as high for small miners but it won't change much for people with 10+GH/s as their variance for payment amounts is already low. The variance due to the low global hashrate can't be solved by tuning N or time between shares but only with more hashrate. Several Avalon customers (myself included) have stated that they will run them on P2Pool, so this problem should go away in the following months if Avalon delivers.

If N is bigger this will probably have some CPU/disk costs too.

A solution to make p2pool more friendly for small miners might be to automatically adjust a miner's difficulty according to the aggregated hashrate of the Bitcoin address it works for. The difficulty would be set to keep share submission around an healthy rate (always higher than the minimum difficulty set by the current P2Pool global hashrate and around a level where variance in payment amounts is considered acceptable if its higher than the minimum). In a later hardfork of the sharechain P2Pool could even enforce a limitation on the number of shares for each payment address in the PPLNS window to make sure a big miner can't circumvent this and take all the place in the sharechain.

There's already code supporting arbitrary high share difficulty for big miners but it's only used on a voluntary basis. I hope its not difficult to implement automatic difficulty change on top of it: this might help attract more small miners (it seems the most of the big ones are still here) by lowering the difficulty they would get on P2Pool.


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
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 11, 2013, 03:19:55 PM
 #4613

Good idea. It will be exactly same as it is now, but 5x greater chance to have block and payout within 5 days

If you are reacting to rav2n_pl post just before yours, I think you are mistaken. Read my previous post: if N remains the same in the PPLNS system payment amounts variance will not change unless big miners leave more place in the sharechain by using a greater difficulty than small miners.

, especially matter for small miners. And LP 50sec will greatly decrease orphan+DOA ratio. Right now there is no point to mine on p2pool unless: we have GPU only with low intensity + we have fast CPU + fast Internet and local node on it. I tried remote nodes with many configurations, with GPUs, many FPGAs, result was always tragic.

The only FPGAs having problems are the ones from BFL in Singles and early Minirigs, I have 16 Spartan6 and don't have any problem on P2Pool with them. But you are right for a local node: P2Pool efficiency takes a hit (although a small one if you have good QoS settings) when you use a high latency connection between the miners and the P2Pool node.

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
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
March 11, 2013, 03:45:05 PM
 #4614

I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 11, 2013, 04:22:35 PM
 #4615

I don't care about variance. I am patient (wise?) enough, to not follow "luck" drama.
I tried Icarus, CM1 and Ztex on remote nodes - result was 10-15% doa/orphan. Absolutely not acceptable. On local p2pool indeed I have nice results, but I cannot afford to run another spare computer 24/7 with Phenom II onboard just to get bitcoind latency lower. I just want to mine on remote nodes like I do with any other central pool. Increasing difficulty is only one solution for this.

In fact it's not a solution at all for this.

Increasing the target delay between shares is the only way to reduce the DOA rate when you have latency between miners and node. But if you do so and don't want to increase variance in payment amounts, you'll have to wait longer for them to stabilize: if N is constant in PPLNS and time between shares is higher, you must mine proportionally longer to reach the full payment amount.

If you do this then most newcomers will be discouraged as first payments will be low for more time. This doesn't help p2pool grow (and make global income variance lower).

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
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
March 11, 2013, 04:56:45 PM
 #4616

So what's your solution for 10-15% rejects?
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 11, 2013, 05:23:38 PM
 #4617

So what's your solution for 10-15% rejects?
What matters is your efficiency vs the rest of P2Pool's network. As long as you average above 97% most of the time you should be fine. You can ignore transient variations: I think (didn't check the code) P2Pool compares your overall stale shares since the node startup vs the recent stale share rate of the network so recent changes in the network make the value computed for efficiency move around.

If your 10-15% are the total rejects as reported by your node, there's no problem (I have 10+% rejects and am usually slightly over 100% efficiency).
If it's the amount of rejects as reported by your miner (should be the amount reported as DOA by P2Pool), then either :
  • you can afford a better setup (less network latency between node and miners and more CPU power if P2Pool is running on a weak CPU): do that
  • you can't: consider other pools based on what you value most (variance in income, total expected income, admin policies, ...)

In the end everyone choose their pool based on their needs. At a time I even split my mining power across several pools. If some of your gear gets high rejects but not all of it, you might want to split too.

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
lenny_
Legendary
*
Offline Offline

Activity: 953



View Profile
March 11, 2013, 05:58:58 PM
 #4618

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well. That's wasting resources, nothing else. When we invest our money and time in something, we should do it right. FPGAs just react too slow to change nonce every couple of seconds, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster. No one is mining of remote p2pool nodes as it will just not work as it is right now.
If you guys are saying there is no solution for that - so beware, because one day p2pool will die.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
March 11, 2013, 06:50:42 PM
 #4619

I think we completely misunderstand each other.
I am talking about:
my FPGA hardware doing 0.01% rejects or less on Bitminter using Stratum. Same hardware, exactly same configuration doing 15% rejects on p2pool. I tried to tweak config and got slightly better results about 10% but that's still not the main case. 15% - That's reported by miner and by p2pool stats as well.

That's much too high. I have ~2.5% rejects on all my Spartan6 (CM1 and Icarus with MPBM). I have 2.6% rejects on my GPUs (5870 and 5970 with cgminer).
So I really don't see any problem with FPGAs and P2Pool: in fact they react slightly faster than my GPUs (cgminer autotune the intensity on each one to react in 50ms).

That's wasting resources, nothing else. When we invest our money and time in something, we should do it right.

They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.

FPGAs just react too slow to change nonce every couple of seconds

Now that's mixing your particular configuration which is clearly not optimized for p2pool and plain FUD (since when the target is a couple of seconds?).

, to top of that add remote node's bitcoind latency + network latency + time to prepare getwork etc... This is just not working for LP= 10s, it's a disaster.

Nope, it isn't a disaster: I earned more with p2pool in 6 months than I would have on a 100% PPS pool since I started (I keep track of each and every payment and compare it to my theoretical income on a no fee PPS pool).

No one is mining of remote p2pool nodes as it will just not work as it is right now.

Probably depends on the actual node and who connects to it: some have better connectivity than others. I used to mine on one of my rented VPS servers with a 45ms round-trip time with my miners and it worked OK (it was around 98% efficiency IIRC).

If you guys are saying there is no solution for that - so beware, because one day p2pool will die.

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution. From what you wrote there are surprising latencies in your setup: it probably isn't for you.

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
K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
March 11, 2013, 06:53:21 PM
 #4620

They don't waste resource, a share is only rejected if it both arrives too late and doesn't solve a block so there's no,zero,0 income wasted by these rejects. I repeat: rejects don't reduce the pool's income.
most ppls are being scared of because they think their rejects are wasted work, donst matter how often u say it, dosnt help Sad we would need somewhat like a FAQ explaining it maybe.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Pages: « 1 ... 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 [231] 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 ... 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!