Bitcoin Forum
December 04, 2016, 02:13:42 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 [401] 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029456 times)
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 14, 2014, 02:49:58 AM
 #8001

No. It's not 'noticed because someone is looking for it' (which is what I think you meant with your analogy?). It is noticed because the 95% confidence interval for income as a fraction of expected income is much wider for lower hashrates than for higher hashrates.

Yes, as a fraction of expected income but ask yourself why that even matters. If you expect to get 0.003 BTC and you get 0.002 BTC (or even in one instance 0 BTC for that matter) how is your life impacted in some major way?

Of course it matters. It matters to people who are hobby miners who try to optimise their equipment. It's hard to optmise if you only see a share every few days.

You're also assuming everyone is a hobby miner with no concern for profit. Just because someone can only afford a low hashrate miner doesn't mean they can treat the investment as a "hobby cost". Lots of countries are poorer than the US.

Daily variance does not reduce your profit.

Only true over long periods of time. The greater the variance, the longer the time. You could have much more than expected for a long time. But then you could have much less than expected for a long time.

People are constantly on here talking about how pools with significant fees are "better" for small miners. That is false. In fact they reduce profit.

I have no opinion on the matter. Giving it some thought though, I think if you have such a low hashrate that you can't be sure you have optimal settings for your miner, then you may need to mine at a larger pool just to see if your optimisations have worked.


Even in the case of looking at mining as a "paycheck" most people getting actual paychecks get paid once a week or every two weeks. Looking at your earnings every single day and expecting them to be some nice flat number every single day is stupid and counterproductive.


I don't know that anyone is arguing that they expect the same amount every day. However, your paycheck is the same each fortnight. If you only receive one payment a fortnight from mining, I can guarantee it will vary significantly each fortnight.

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

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

Posts: 1480860822

View Profile Personal Message (Offline)

Ignore
1480860822
Reply with quote  #2

1480860822
Report to moderator
1480860822
Hero Member
*
Offline Offline

Posts: 1480860822

View Profile Personal Message (Offline)

Ignore
1480860822
Reply with quote  #2

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

Posts: 1480860822

View Profile Personal Message (Offline)

Ignore
1480860822
Reply with quote  #2

1480860822
Report to moderator
1480860822
Hero Member
*
Offline Offline

Posts: 1480860822

View Profile Personal Message (Offline)

Ignore
1480860822
Reply with quote  #2

1480860822
Report to moderator
irrational
Jr. Member
*
Offline Offline

Activity: 56


View Profile
March 14, 2014, 03:40:12 AM
 #8002

this:

Daily variance does not reduce your profit.

Only true over long periods of time. The greater the variance, the longer the time.

and:

Even in the case of looking at mining as a "paycheck" most people getting actual paychecks get paid once a week or every two weeks. Looking at your earnings every single day and expecting them to be some nice flat number every single day is stupid and counterproductive.


I don't know that anyone is arguing that they expect the same amount every day. However, your paycheck is the same each fortnight. If you only receive one payment a fortnight from mining, I can guarantee it will very significantly each fortnight.

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

To tie the second bolded text back into your first bolded text, it's not so much the +/- swing, it's that with smaller hash rates you're "rolling the dice" less often, and thusly (as you alluded to in the first bolded text) might not levelize for a VERY long period of time.

I'm sure you knew that, but since they were separated in your post I figured I'd point that out in case others didn't pick up on that.

14Cow1HA12umeV3zdZXNmrE3TsnYaaf4Q5
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 03:49:05 AM
 #8003

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.


I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 03:51:14 AM
 #8004

I have no opinion on the matter. Giving it some thought though, I think if you have such a low hashrate that you can't be sure you have optimal settings for your miner, then you may need to mine at a larger pool just to see if your optimisations have worked.

If you are mining on a public node, you can measure how well you have "optimized" your miner using the pseudo-shares (reported by your miner) and the overall efficiency of the public node. There is no real difference between pseudo-shares and real shares from the point of view of an external miner using a public node (other than a difficulty of course).

If you are trying to optimize your own p2pool node with a tiny hash rate, you are certainly not doing it to maximize return on investment, because you can't possibly justify the cost a p2pool node (and full bitcoin node) for a tiny hash rate on an objective basis.

organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 14, 2014, 03:53:11 AM
 #8005

To tie the second bolded text back into your first bolded text, it's not so much the +/- swing, it's that with smaller hash rates you're "rolling the dice" less often, and thusly (as you alluded to in the first bolded text) might not levelize for a VERY long period of time.

I'm sure you knew that, but since they were separated in your post I figured I'd point that out in case others didn't pick up on that.

Sure. If you take an extreme case, you can show that as long as difficulty doesn't ever drop below current difficulty, it's more likely that mining at a pool will return any amount of reward compared to mining solo - if the income chunks are large enough, one chunk may be greater than the expected earning of the small hashrate miner. In this case, it would be more probable than any amount of bitcoin could be earned at pooled mining than solo.

This reductio ab adsurdum also applies to p2Pool, but to a much lesser extent.

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

Activity: 1246



View Profile
March 14, 2014, 03:53:32 AM
 #8006

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.


I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 03:59:40 AM
 #8007

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

It's significant only insofar as people make it out to be significant. If a hobby miner's earnings vary from $10 to $0, that might well be less significant than a larger scale miner whose earnings drop from $5000 to $4000 but who spent many thousands of dollars on mining gear and has an electricity bill of hundreds or thousands of dollars per month. A $10 shortfall is a $10 shortfall, and can't ever make more than a $10 difference. You can't change that at putting some scary percentage number on it.

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.




organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 14, 2014, 03:59:50 AM
 #8008

BTW it's kinda a bummer the max share chain is only 3 days. The SPREAD is 3 blocks worth of work, so that would normally mean any share someone finds should get one or more payouts. Is the reason we have a max share chain length at all to prevent abuse? I'd think the share chain should expand as much as needed automatically to store SPREAD worth of payouts...

If you pay shares on every single block you have proportional payout (subject to pool hopping abuse), not PPLNS.


I think you didn't understand my point. If the window (N) for PPLNS is large enough then shares should get paid on every block as well. That doesn't make it the proportional. The problem right now is the share window is shorter than the time to find a block, so some shares don't get any payments at all, in spite of SPREAD being set to 3. (That is, the payment window is 3 * difficulty.) As I understand it, the share chain length overrides the spread, so the payment window will fluctuate based on however much work fits in the share chain instead of the most recent N.

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

Time based PPLNS is a bit unstable. It's a variance vs time-to-maturity trade-off. If p2Pool's PPLNS was only share based, then you'd see consistent variance in total earned, but a varying time to maturity (how long it take a share to leave the PPLNS window).

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:03:53 AM
 #8009

There is no length that is necessarily guaranteed to be long enough. If you are saying to extend the chain until blocks are found, that is exactly what proportional payout does.

If you are just suggesting to extend the chain to some other fixed length like 7 days or 30 days or something else, that is another story, with its own tradeoffs. For example, even people with large hash rates will see very small payouts for a long time when first starting.

Even 7 days probably won't be long enough soon.

I'm saying let the sharechain grow as large as needed to hold the full PPLNS window size, like all normal PPLNS pools do.

I'm not sure if I'm doing the math right here, but -ln(1.0 - .95) = about 3. So 95% of all blocks should be found within 3 * difficulty shares worth of work. That is, only 5% of shares should result in no payment at all. organofcorti please chime in if I did this wrong.

But if the share chain is capped at 3 days worth of shares regardless of the difficulty of finding a block and regardless of the amount of work stored in the chain, instead of always at N = 3 * difficulty, then the size of N for the PPLNS payment window shrinks and the % of shares resulting in no payment goes up. This doesn't happen in traditional PPLNS pools, N remains fixed and the % from above remains fixed.

Caveat: I don't know the inner workings of how p2pool juggles the share chain size and spread variables to come up with it's minimum share target difficulties.

RoyalMiningCo: Pools retired. Was fun!
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:06:06 AM
 #8010

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

p2pool already works well with large miners. Cointerra's products work wonderfully with it. It isn't a technical challenge, it's a marketing/advertising/perception one. Why don't the bulk of CT users mine with p2pool instead of some other pool? That's the question. If I owned a huge farm, using p2pool would be an automatic choice.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 04:09:10 AM
 #8011

p2pool already works well with large miners. Cointerra's products work wonderfully with it. It isn't a technical challenge, it's a marketing/advertising/perception one.

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split, and it means I can't really open up my node for public use, which I might otherwise do. (There are no public nodes in my geographic area as far as I can tell.) Marketing and awareness are also important of course.

roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:19:00 AM
 #8012

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split. Marketing and awareness are also important of course.

I chatted with someone on #p2pool once who did a probabilistic payout model for a group of people who mined with him on his private node. That's more random for the people you are paying than if you collect the coins yourself and then pay them evenly. But of course that does open yourself up to wallet theft, etc. I'm a big fan of paying directly to people and not holding coins whenever possible.

So for example, if you had 10 investors who own 10% each of the pool, then you wouldn't use the incoming miner addresses at all. You'd customize the payout code so each of those addresses had a 10% chance of being chosen as the one going into the p2pool share chain (like the way fees work). The problem is if investors get upset than investor A is being paid more than B, since it's random. A more advanced approach could record the payments actually paid out to the investors on the blockchain to their group buy addresses, and mine to the investor address who has received the least payments. Sort of a payment round robin approach, so one investor can't get too far ahead of another due to randomness. (Adjusted as needed of course if miners don't have equal ownership stakes.)

So someone in your example might find that useful. But it'd be easy enough to code without needing it as an official function for everyone.

Edit: I'm always trying to think of ways to run p2pool public nodes profitably. The proxy pool project is pretty cool and I ported that to vertcoin but didn't make a payment backend system yet. However your comment about farms/group buys wanting a feature to break out their payments in arbitrary ways more complex than just 'everything to this address' could be a value added feature worth implementing.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 04:23:06 AM
 #8013

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split. Marketing and awareness are also important of course.

I chatted with someone on #p2pool once who did a probabilistic payout model. That's more random for the people you are paying than if you collect the coins yourself and then pay them evenly. But of course that does open yourself up to wallet theft, etc. I'm a big fan of paying directly to people and not holding coins whenever possible.

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

I don't really agree that "you could code it yourself" is a good answer to a missing function that could attract more miners. I obviously don't know how many miners this particular function would attract.


roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:24:47 AM
 #8014

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

Were you the one I chatted with about it on #p2pool? It's been long enough I don't recall who it was now. Smiley

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 04:26:40 AM
 #8015

Yes it is added variance. This is accepted in understood by the participants in my case. In practice the payouts seem to be fairly close (it is shares that are being split probabilistically and over the payment window the number of shares is fairly large). As you said it reduces the changes of wallets being compromised and other problems.

Were you the one I chatted with about it on #p2pool? It's been long enough I don't recall who it was now. Smiley

No not me. I'm only splitting two ways so the fee function works for that. I did consider at one point that if I needed to split more ways I would find the fee function (random split) in the code and modify it, but I haven't needed it yet.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 14, 2014, 04:32:00 AM
 #8016

To be clear: I am not arguing that p2Pool should be made more minable by smaller miners. I am explaining to you how CDFs vary significantly for different hashrates. Someone with a large hashrate might see a +/- 1% variation in earnings per week. Someone with a small hashrate might see earnings change to 0.01% or 1000% of the previous week's earnings. I think you're not understanding how significant that is.

It's significant only insofar as people make it out to be significant. If a hobby miner's earnings vary from $10 to $0, that might well be less significant than a larger scale miner whose earnings drop from $5000 to $4000 but who spent many thousands of dollars on mining gear and has an electricity bill of hundreds or thousands of dollars per month. A $10 shortfall is a $10 shortfall, and can't ever make more than a $10 difference. You can't change that at putting some scary percentage number on it.

In any case, as I suggested earlier, the focus on very small miners is misguided. What p2pool needs is more large miners. Adding a few thousand 5 GH miners won't make any real difference. Getting KnC or whoever that was to mine their 1000 TH on p2pool instead of eligius changes the whole picture.

I'm not following, bud. Are you going off on a tangent here? Wink Or maybe what you address in this post isn't really my concern? I'm not saying it's bad, or wrong, just not my concern.

Either way I'm fine with that, but I want to be certain you weren't still discussing the difference between large and small miner variance.

In case you are, or in case there are other readers as confused as I, you can think about it like this: the number of p2Pool shares a miner submits per time period is an approximately Poisson distributed random number. This means that the standard deviation of this number is proportional to the square root of the mean. As the share submission rate increases, the standard deviation only increases as the square root of the mean, so a miner with a greater share submission rates has, proportionally, a much lower standard deviation.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:33:53 AM
 #8017

No not me. I'm only splitting two ways so the fee function works for that. I did consider at one point that if I needed to split more ways I would find the fee function (random split) in the code and modify it, but I haven't needed it yet.

Ah ok. In addition to the struggle to think of things that would entice miners to use my nodes for some appropriate fee %, there's also the feeling anything I do I should just commit to the project and make open source as well. Which, of course, then ends up giving me nothing but a sense of accomplishment but no way to pay for my servers. Smiley

RoyalMiningCo: Pools retired. Was fun!
roy7
Sr. Member
****
Offline Offline

Activity: 434


View Profile
March 14, 2014, 04:43:38 AM
 #8018

Yes that is the question. I'm not sure you can flat out dismiss "technical" concerns. Maybe things like graphs and so forth are important. There may be other feature issues. For example, I know a few people have mentioned automatic splitting of payouts for farms with investors and group buys as being an attractive feature of ghash.io. I'm personally using the fee function in p2pool for that, but that only gives a two-way split, and it means I can't really open up my node for public use, which I might otherwise do. (There are no public nodes in my geographic area as far as I can tell.) Marketing and awareness are also important of course.

Honestly until you mentioned it this evening I'd never even seen this sort of feature mentioned before. I did some searching and here's a post talking about exactly what you said, and it is why they use ghash.io:

https://bitcointalk.org/index.php?topic=406194.msg4409010#msg4409010

The only issue is ghash.io is holding your coins, and they pay out on precise %s. In p2pool's world, you can't split a share like that so the best you can do is approximate it by allocating work with the mining address assigned out with the %s you want to pay out to. Which won't be as exact.

Edit: You know, it'd be possible to code this up where it's all passed in the username. Does a pool username have a max length in programs like cgminer/bfgminer? Since + and / are already used, one could add support in p2pool for a syntax like ADDR1*.5,ADDR2*.3,ADDR3*.2 as your username to split the payment address in work servers to your miner(s) randomly between those addresses at those %s.

RoyalMiningCo: Pools retired. Was fun!
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
March 14, 2014, 05:13:16 AM
 #8019

In case you are, or in case there are other readers as confused as I, you can think about it like this: the number of p2Pool shares a miner submits per time period is an approximately Poisson distributed random number. This means that the standard deviation of this number is proportional to the square root of the mean. As the share submission rate increases, the standard deviation only increases as the square root of the mean, so a miner with a greater share submission rates has, proportionally, a much lower standard deviation.

The key word you are using there, which contributes much to the confusion, is proportionately. In fact the standard deviation, measured in units of dollars, btc, or anything else is higher for the larger miner. It grows more slowly than the mean, but it still grows. A small miner has a small standard deviation in absolute terms.

organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1946


Poor impulse control.


View Profile WWW
March 14, 2014, 05:32:45 AM
 #8020

In case you are, or in case there are other readers as confused as I, you can think about it like this: the number of p2Pool shares a miner submits per time period is an approximately Poisson distributed random number. This means that the standard deviation of this number is proportional to the square root of the mean. As the share submission rate increases, the standard deviation only increases as the square root of the mean, so a miner with a greater share submission rates has, proportionally, a much lower standard deviation.

The key word you are using there, which contributes much to the confusion, is proportionately. In fact the standard deviation, measured in units of dollars, btc, or anything else is higher for the larger miner. It grows more slowly than the mean, but it still grows. A small miner has a small standard deviation in absolute terms.

Yes, we've covered that before, but there's no point in considering "absolute terms". Few people consider anything related to BTC in "absolute terms". In fact I can't think of many situations in which there are useful BTC related charts which are not log-linear.


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
Pages: « 1 ... 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 [401] 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 ... 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!