Bitcoin Forum
November 30, 2021, 04:13:27 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 ... 179 »
  Print  
Author Topic: [ANN][YAC] YACoin ongoing development  (Read 378911 times)
WindMaster
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 22, 2013, 08:49:32 AM
Last edit: May 22, 2013, 09:09:23 AM by WindMaster
 #261

TBH, I don't think transparency & honesty is the essence & key for trust. Do you imagine what if some one takes off all his clothes & pants and you then give your precious trust? This is silly and pity.

I don't quite follow that analogy.  Are you suggesting it would be better if I sugar-coat everything and say there's no possibility GPU implementations exist?  I'm not sure that would do much to increase trust..  I'm fairly certain no one wants to see me naked either.  Smiley
1638288807
Hero Member
*
Offline Offline

Posts: 1638288807

View Profile Personal Message (Offline)

Ignore
1638288807
Reply with quote  #2

1638288807
Report to moderator
1638288807
Hero Member
*
Offline Offline

Posts: 1638288807

View Profile Personal Message (Offline)

Ignore
1638288807
Reply with quote  #2

1638288807
Report to moderator
1638288807
Hero Member
*
Offline Offline

Posts: 1638288807

View Profile Personal Message (Offline)

Ignore
1638288807
Reply with quote  #2

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

Posts: 1638288807

View Profile Personal Message (Offline)

Ignore
1638288807
Reply with quote  #2

1638288807
Report to moderator
hanzac
Sr. Member
****
Offline Offline

Activity: 425
Merit: 262


View Profile
May 22, 2013, 09:06:22 AM
 #262

I don't quite follow that analogy.  Are you suggesting it would be better if I sugar-coat everything and say there's no possibility GPU implementations exist?

I just want to say that most common people also expect respect in the first place. Transparency and honesty are too much for them sometimes. For the GPU implementations also have this effect, if the community shows more respect for the software developers, they will give much more instead of hiding innovative things / creating copy-cats / gold rushes / etc.

You did right to tell the truth, but things are not just easy to expand.
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
May 22, 2013, 01:29:20 PM
 #263

Solid, within a year hashes will go from MH/s to double digit H/s  Roll Eyes  Network difficulty will drop like crazy and block reward will explode, destroying any value the coin might have had.

While I often agree with a number of the things you've said, I'm worried you're starting to exaggerate.  In the main YACoin thread, today you posted that anyone could've developed a GPU miner days in advance, yet only the original developer (and anyone he tipped off) could've been aware he was going to pull a surprise move and use a different hashing algorithm than anyone was expecting.  Changing from scrypt+salsa20/8+SHA256(1024,1,1) to scrypt+chacha20/8+Keccak512(N,1,1) did turn out to be significantly more than just a copy-paste exercise from the scrypt-jane library source, at least for anything that was going to go faster on GPU's than typical desktop CPU's.

In your comment above, I think your numbers are exaggerated a bit.  I just benchmarked with a Linux build of cpuminer and forced N to various values:

Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k).

For N=32 (at coin's launch), hash rate = 358.77 kH/sec
For N=256 (right now), hash rate = 119.25 kH/sec
For N=32768 (in one year), hash rate = 0.606 kH/sec

So, anyway, when I see exaggerations that are off by 2 orders of magnitude, I'm afraid I'll have to call you out on it (as much as I respect you).  I'd prefer to see you discredit a coin with accurate info, not exaggerations.

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

You need to address the problem with block reward with a hard fork as soon as possible, in my opinion.  You'll probably end up with a slightly more valuable coin if you relaunch it later forking from the litecoin code instead once the GPU miner has been released.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
ilostcoins
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250



View Profile
May 22, 2013, 03:28:02 PM
 #264

I have an off topic question, and hopefully someone may be in the mood to enlighten me.  Smiley

What kind of work is better done on the vector units of CPU rather than the GPU, provided the GPU isn't too busy doing things like rendering? My first interest about this question came from gaming hardware, but then thought it may relate to people designing a coin for which GPU has less of an advantage in mining.

LTC: LSyqwk4YbhBRtkrUy8NRdKXFoUcgVpu8Qb   NVC: 4HtynfYVyRYo6yM8BTAqyNYwqiucfoPqFW   TAG id: 4313
CMC: CAHrzqveVm9UxGm7PZtT4uj6su4suxKzZv   YAC: Y9m5S7M24sdkjdwxnA9GZpPez6k6EqUjUt
WindMaster
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 22, 2013, 04:32:17 PM
Last edit: May 22, 2013, 04:55:02 PM by WindMaster
 #265

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

Solid, within a year hashes will go from MH/s to double digit H/s  Roll Eyes  Network difficulty will drop like crazy and block reward will

You were off by a pretty large amount at both ends of the numbers you said hash rate would traverse over the course of a year.  However, with a more thorough calculation:

Best interpretation (most favorable to you) of your statement is that hash rates go from 1MH/sec to 99.999 H/sec over the course of the first year, a decrease in speed of about 10000x.  My benchmark showed a decrease of speed over the course of the first year of 358.77kH/sec to 0.606kH/sec with one particular common server CPU, a decrease in speed of about 592x.

10000 vs 592.  Or we could calculate that as 10000 / 592 = 16.9 and call that a single order of magnitude (plus change).  A strict interpretation of Wikipedia's "order of magnitude" article would suggest that this is the correct way.  So, I concede that you were off by a bit more than an order of magnitude if we analyze the most favorable interpretation of your statement.


I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized.

Was the scrypt-jane library available somewhere prior to September 13, 2012?  If so, I'd like to snag a copy of that earlier version you benchmarked with.  Which hashing algorithm in the scrypt-jane library was that benchmark performed with?
mtrlt
Member
**
Offline Offline

Activity: 104
Merit: 10


View Profile
May 22, 2013, 06:25:23 PM
 #266

I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.
smilez
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
May 22, 2013, 06:40:16 PM
 #267

So people can GPU mine yacoin now?:O
seleme
Legendary
*
Offline Offline

Activity: 2170
Merit: 1012


Duelbits.com


View Profile WWW
May 22, 2013, 06:42:30 PM
 #268

pocopoco really made some kick ass coin, shame he used his alter ego for it and never looked back at it.

With all these copycats out there recently it's the only coin that took some time and skills to be made.

Duelbits            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀

Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█

Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █

Blackjack
|              ▄▄▀▀█▌
          ▄▄▀█▄    █
        ▄▀     ▀▄▄ █
       █    ▄▄    ▀█
    ▄▄█    █  █   ▐▌
  ▄▀ █      ▀▀    █
▄▀  ▐▌           █
█ ▄▀▀▄▄        ▄▀
▀▀  ▄  ▀▄▄   ▄▀█
  ▄▀   ▄  ▀█▀  █
   ▄▀ ▄▀   █  █
  ▄▀ █     █▄▀
   ▄▀
NEW GAME!
..CRASH...
|||
[ Đ ][ Ł ]
AVAILABLE NOW
smilez
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
May 22, 2013, 06:43:50 PM
 #269

So who is pocopoco?
seleme
Legendary
*
Offline Offline

Activity: 2170
Merit: 1012


Duelbits.com


View Profile WWW
May 22, 2013, 06:46:36 PM
 #270

YaCoin creator

Duelbits            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀

Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█

Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █

Blackjack
|              ▄▄▀▀█▌
          ▄▄▀█▄    █
        ▄▀     ▀▄▄ █
       █    ▄▄    ▀█
    ▄▄█    █  █   ▐▌
  ▄▀ █      ▀▀    █
▄▀  ▐▌           █
█ ▄▀▀▄▄        ▄▀
▀▀  ▄  ▀▄▄   ▄▀█
  ▄▀   ▄  ▀█▀  █
   ▄▀ ▄▀   █  █
  ▄▀ █     █▄▀
   ▄▀
NEW GAME!
..CRASH...
|||
[ Đ ][ Ł ]
AVAILABLE NOW
smilez
Newbie
*
Offline Offline

Activity: 56
Merit: 0



View Profile
May 22, 2013, 06:51:31 PM
 #271

YaCoin creator

I know that, but you said he used his alter ego. Smiley

So pocopoco should be someone else.
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 802
Merit: 1003


GCVMMWH


View Profile
May 22, 2013, 08:17:22 PM
 #272

With all these copycats out there recently it's the only coin that took some time and skills to be made.

It's interesting and unique enough (as indicated by the speculation and debates it provides (such as those by WM and taco))  that I've kept an eye on it since day one. The only thing that the cookie cutter coins have provided is a point-and-shoot solution for the pump~dumpers. YAC has some substance, which - along with active development, should hopefully keep it viable for the long term.    
seleme
Legendary
*
Offline Offline

Activity: 2170
Merit: 1012


Duelbits.com


View Profile WWW
May 22, 2013, 08:19:45 PM
 #273

YaCoin creator

I know that, but you said he used his alter ego. Smiley

So pocopoco should be someone else.

I don't have a proof for that but I'm fairly sure he is some other guy. He is obviously very knowledgeable and I don't think he appeared just like that.

Damn, I guess WindMaster might have some other nick too Smiley

Duelbits            ▄████▄▄
          ▄█████████▄
        ▄█████████████▄
     ▄██████████████████▄
   ▄████▄▄▄█████████▄▄▄███▄
 ▄████▐▀▄▄▀▌████▐▀▄▄▀▌██

 ██████▀▀▀▀███████▀▀▀▀█████

▐████████████■▄▄▄■██████████▀
▐██████████████████████████▀
██████████████████████████▀
▀███████████████████████▀
  ▀███████████████████▀
    ▀███████████████▀
.
         ▄ ▄▄▀▀▀▀▄▄
         ▄▀▀▄      █
         █   ▀▄     █
       ▄█▄     ▀▄   █
      ▄▀ ▀▄      ▀█▀
    ▄▀     ▀█▄▄▄▀▀ ▀
  ▄▀  ▄▀  ▄▀

Live Games

   ▄▄▀▀▀▀▀▀▀▄▄
 ▄▀ ▄▄▀▀▀▀▀▄▄ ▀▄
▄▀ █ ▄  █  ▄ █ ▀▄
█ █   ▀   ▀   █ █  ▄▄▄
█ ▀▀▀▀▀▀▀▀▀▀▀▀▀ █ █   █
█▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀█  █▄█
█ ▀▀█  ▀▀█  ▀▀█ █  █▄█

Slots
.
        ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄
        █         ▄▄  █
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▄       █
█  ▄▄         █       █
█             █       █
█   ▄▀▀▄▀▀▄   █       █
█   ▀▄   ▄▀   █       █

Blackjack
|              ▄▄▀▀█▌
          ▄▄▀█▄    █
        ▄▀     ▀▄▄ █
       █    ▄▄    ▀█
    ▄▄█    █  █   ▐▌
  ▄▀ █      ▀▀    █
▄▀  ▐▌           █
█ ▄▀▀▄▄        ▄▀
▀▀  ▄  ▀▄▄   ▄▀█
  ▄▀   ▄  ▀█▀  █
   ▄▀ ▄▀   █  █
  ▄▀ █     █▄▀
   ▄▀
NEW GAME!
..CRASH...
|||
[ Đ ][ Ł ]
AVAILABLE NOW
Sunny King
Legendary
*
Offline Offline

Activity: 1205
Merit: 1003



View Profile WWW
May 22, 2013, 08:37:57 PM
 #274

It's good that yacoin did not change the 1 week average window of ppcoin's adjustment. So the attack can only change difficulty by ~2.5% for the next block, which may or may not be attacker's block.

This is not an exploit specific to the continuous difficulty adjustment of ppcoin. In bitcoin style step adjustment, an attacker can manipulate the timestamp of the last block of an adjustment interval. If attacker manages to mine the last block of an adjustment interval, the entire next interval's difficulty could be lowered. That's why one should stay with a longer adjustment window.

Bitcoin has +/- 2 hours maximimum block time offset since ages. I think it does not really matter much if block time is valid or not for as long as miner who added such block to
blockchain stays under 50% of network hashpower. Difficulty calculation takes block times in equation but one or few screwed blocks can't screw the result much. If some miner
would have 50% or more of network hashpower he could ruin difficulty calculation but he could ruin many other things as well, including much more important stuff than difficulty.

But make no mistake, some miner or few of them are playing with YAC block times on purpose. By putting block time in the future, he wants to affect difficulty calculation in such
a way that resulting difficulty is lower than it should be. Difficulty will "think" it took much longer than 60 seconds to find that specific block so it will adjust result downward, a bit.
wetroof
Member
**
Offline Offline

Activity: 75
Merit: 10


View Profile
May 22, 2013, 08:41:03 PM
 #275

why does n stay at 512 for only a few days?

7      256      32kB      1369039776      Mon - 20 May 2013 - 08:49:36 GMT
8      512      64kB      1369826208      Wed - 29 May 2013 - 11:16:48 GMT
9      1024      128kB   1370088352      Sat - 01 Jun 2013 - 12:05:52 GMT



I appreciate all the discussion in this thread. and specifically the posts by windmaster.
WindMaster
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 22, 2013, 08:48:00 PM
 #276

why does n stay at 512 for only a few days?

The actual code that calculates the Nfactor isn't a nice smooth progression, it combines a couple calculations together that each cause Nfactor to change on different intervals.  The actual code in main.cpp looks like this, if curious:

Code:
int64 nChainStartTime = 1367991200;

const unsigned char minNfactor = 4;
const unsigned char maxNfactor = 30;

unsigned char GetNfactor(int64 nTimestamp) {
    int l = 0;

    if (nTimestamp <= nChainStartTime)
        return 4;

    int64 s = nTimestamp - nChainStartTime;
    while ((s >> 1) > 3) {
      l += 1;
      s >>= 1;
    }

    s &= 3;

    int n = (l * 170 + s * 25 - 2320) / 100;

    if (n < 0) n = 0;

    if (n > 255)
        printf( "GetNfactor(%lld) - something wrong(n == %d)\n", nTimestamp, n );

    unsigned char N = (unsigned char) n;
    //printf("GetNfactor: %d -> %d %d : %d / %d\n", nTimestamp - nChainStartTime, l, s, n, min(max(N, minNfactor), maxNfa

    return min(max(N, minNfactor), maxNfactor);
}
rbdrbd
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250



View Profile
May 22, 2013, 09:00:57 PM
 #277

I did some GPU testing with high N values. The gist is: at N=8192, I couldn't get it to output valid shares any more. Therefore, with current information, it seems that GPU mining will stop on 13 Aug 2013 - 07:43:28 GMT when N goes to 8192.

Very interesting news. Might there be some additional optimizations that you could do to get it to output (perhaps like messing with the lookup gap or some other TMTO hacks?)

I'm wondering two things:
a) why do you think it stopped working at 8192 (physical GPU limitation with current gen GPUs, or more a limitation of the code that can be more easily overcome)?
b) does CPU mining still work at 8192 and beyond? (if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).

Thanks for your insightful work on the GPU miner around YAC.
bitdwarf
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


The cryptocoin watcher


View Profile
May 22, 2013, 09:19:19 PM
 #278

Since we are doing some Q & A, I've been wondering if an insane high N would (painfully try to) use swap memory.

𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme
Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
WindMaster
Sr. Member
****
Offline Offline

Activity: 347
Merit: 250


View Profile
May 22, 2013, 09:25:22 PM
 #279

b) does CPU mining still work at 8192 and beyond?

Benchmark and test run at N=32768 I ran and posted on the previous page to dispute TacoTime's claim hash rates will drop to double digits in a year:

Quote
Platform: IBM HS21 blade server, 2x Xeon E5450's (similar combined performance to one i7-2600k).

For N=32 (at coin's launch), hash rate = 358.77 kH/sec
For N=256 (right now), hash rate = 119.25 kH/sec
For N=32768 (in one year), hash rate = 0.606 kH/sec

(if not, then we have a problem on our hand that would at minimum necessitate a hard fork I'd think).

If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork.
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
May 22, 2013, 09:28:37 PM
 #280

I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized. Also note that above you hash in the hundreds of hashes per second; I said that you would hit "double digits of H/s", making the difference one order of magnitude, not two.

Solid, within a year hashes will go from MH/s to double digit H/s  Roll Eyes  Network difficulty will drop like crazy and block reward will

You were off by a pretty large amount at both ends of the numbers you said hash rate would traverse over the course of a year.  However, with a more thorough calculation:

Best interpretation (most favorable to you) of your statement is that hash rates go from 1MH/sec to 99.999 H/sec over the course of the first year, a decrease in speed of about 10000x.  My benchmark showed a decrease of speed over the course of the first year of 358.77kH/sec to 0.606kH/sec with one particular common server CPU, a decrease in speed of about 592x.

10000 vs 592.  Or we could calculate that as 10000 / 592 = 16.9 and call that a single order of magnitude (plus change).  A strict interpretation of Wikipedia's "order of magnitude" article would suggest that this is the correct way.  So, I concede that you were off by a bit more than an order of magnitude if we analyze the most favorable interpretation of your statement.


I benched at around 100 ms/hash per thread with a 2700k when using 8 MB.  This was more than a year ago using scrypt jane, so maybe the code has been optimized.

Was the scrypt-jane library available somewhere prior to September 13, 2012?  If so, I'd like to snag a copy of that earlier version you benchmarked with.  Which hashing algorithm in the scrypt-jane library was that benchmark performed with?

You're a feisty one.  You're correct on the date, it was during the memcoin thread which was apparently November of last year, so I guess only six months old.  Guess my memory slipped, but things move quickly these days.

Quote
If the scrypt-jane library starts having trouble at certain values of N (and it looks fine up through at least N=32768 that I've tested so far), I'd think we would only need to fix the problem in the library and release a new update to the client, rather than hard fork.

It works fine above that, I've used it beyond 32768 (see that thread).

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 [14] 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 ... 179 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!