Bitcoin Forum
April 20, 2024, 05:06:21 AM *
News: Latest Bitcoin Core release: 26.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 ... 62 »
  Print  
Author Topic: MC2: A cryptocurrency based on a hybrid PoW/PoS system  (Read 195081 times)
chriswen
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500


View Profile
April 07, 2013, 11:12:25 PM
 #61

Okay, so that the first PoS blocks will be mined in 180 days!
1713589581
Hero Member
*
Offline Offline

Posts: 1713589581

View Profile Personal Message (Offline)

Ignore
1713589581
Reply with quote  #2

1713589581
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
BubbleBoy
Sr. Member
****
Offline Offline

Activity: 504
Merit: 250



View Profile
April 07, 2013, 11:14:30 PM
 #62

I really don't understand the rationale behind these hybrid PoS/PoW systems. You can either solve the Byzantine consensus problem with proof of stake, or you can't. In the first case there's no need for wasteful proof of work. In the second case it makes no sense to complicate the design with something that does not add security. It's as if the designers want PoS, haven't quite figure it out how to achieve it, and add PoW for good measure just in case their PoS scheme turns out to be vacuous.

The same can be said about the baroque "polymorphic" hash. If your goal is memory hardness and a small performance opportunity for custom hardware, you should design a scheme specifically tuned for CPU implementation - if such a thing is indeed possible. A hodgepodge of all hashes under the sun while hoping the ASIC designers won't bother to implement them all is security through "copypasting lots of code".

                ████
              ▄▄████▄▄
          ▄▄████████████▄▄
       ▄██████▀▀▀▀▀▀▀▀██████▄
     ▄████▀▀            ▀▀████▄
   ▄████▀                  ▀████▄
  ▐███▀                      ▀███▌
 ▐███▀   ████▄  ████  ▄████   ▀███▌
 ████    █████▄ ████ ▄█████    ████
▐███▌    ██████▄████▄██████    ▐███▌
████     ██████████████████     ████
████     ████ ████████ ████     ████
████     ████  ██████  ████     ████
▐███▌    ████   ████   ████    ▐███▌
 ████    ████   ████   ████    ████
 ▐███▄   ████   ████   ████   ▄███▌
  ▐███▄                      ▄███▌
   ▀████▄                  ▄████▀
     ▀████▄▄            ▄▄████▀
       ▀██████▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████▀▀
              ▀▀████▀▀
                ████
MIDEX
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂ GET TOKENS ▂▂▂▂
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
BLOCKCHAIN BASED FINANCIAL PLATFORM                                # WEB ANN + Bounty <
with Licensed Exchange approved by Swiss Bankers and Lawyers           > Telegram Facebook Twitter Blog #
strunberg
Sr. Member
****
Offline Offline

Activity: 1302
Merit: 324


#SWGT PRE-SALE IS LIVE


View Profile WWW
April 07, 2013, 11:27:15 PM
 #63

Why not create a tier system that benefits those who have little Hashing power?
With byte coin individuals ave already mined thousands of coins.
Where people with a single GPU and a hash rate of a hundred or so, suffer as they have  under 100 coins even after mining for days.

My idea is that for every additional GPU, your hashing power is reduced more and more with a tax.
What is reduced is actually sent to a community faucet. As time goes on, that tax is reduced more and more as the difficulty increases.
This tax rate is linked to your ip address,in order to stop tax evaders.

This tax also prevents the price of this new coin from imploding on day one, within hours when it first goes to market.


We also need to prevent ASIC bombing some how.
If you have an ASIC,why should we allow you to blow up the difficulty to that of Bit coin, almost over night and ruin this alt-coin?


.SWG.io.













█▀▀▀










█▄▄▄

▀▀▀█










▄▄▄█







█▀▀▀










█▄▄▄

▀▀▀█










▄▄▄█







``█████████████████▄▄
``````▄▄▄▄▄▄▄▄▄▄▄▄████▄
````````````````````▀██▄
```▀▀▀▀``▀▀▀▀▀▀▀▀▀▀▀▄███
``````▄▄▄▄▄▄▄▄▄▄▄▄``▄███
``▄▄▄▄▄▄▄```▄▄▄▄▄``▄███
``````````````````▄██▀
```````````████████████▄
````````````````````▀▀███
`````````▀▀▀▀▀▀▀▀▀▀▀▀▄████
```▄▄▄``▄▄▄▄▄▄▄▄▄▄`````███
`▄▄▄▄▄▄▄▄▄``▄▄▄▄▄▄`````███
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀████
```````````````````▄▄████
``▀▀▀▀▀``▀▀▀▀▀▀▀▀▀█████
██``███████████████▀▀

FIRST LISTING
CONFIRMED






codro
Member
**
Offline Offline

Activity: 91
Merit: 10


View Profile
April 07, 2013, 11:47:41 PM
 #64

Naming cryptocurrency 'coins' has bothered me - at least since the alts had a chance of fixing this.

It's the type of http://en.wikipedia.org/wiki/Skeuomorphism that may not make much sense a few years from now. And Skeumorphs are bad in general. Smiley

We should come up with a better suffix than -coin if this is an alt. Perhaps something deriving from "credits", which seems to be what most SciFi authors call future money.

Also, I like the idea here regarding reducing the massive profits of early adopters:
https://bitcointalk.org/index.php?topic=169623.0
saigo
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
April 07, 2013, 11:55:15 PM
Last edit: April 08, 2013, 12:05:31 AM by saigo
 #65

I quite like 'coin', think of them as digital coins. Each BTC made up of millions of small satoshi digi coins.

I also think the rewards to early adopters are required, else there may be no early adopters

Saigō Takamori : ( 1828 – 1877) was one of the most influential samurai in Japanese history. He has been dubbed the last true samurai.
qxzn
Hero Member
*****
Offline Offline

Activity: 609
Merit: 505



View Profile
April 08, 2013, 12:32:53 AM
 #66

I really don't understand the rationale behind these hybrid PoS/PoW systems. You can either solve the Byzantine consensus problem with proof of stake, or you can't. In the first case there's no need for wasteful proof of work. In the second case it makes no sense to complicate the design with something that does not add security. It's as if the designers want PoS, haven't quite figure it out how to achieve it, and add PoW for good measure just in case their PoS scheme turns out to be vacuous.

The same can be said about the baroque "polymorphic" hash. If your goal is memory hardness and a small performance opportunity for custom hardware, you should design a scheme specifically tuned for CPU implementation - if such a thing is indeed possible. A hodgepodge of all hashes under the sun while hoping the ASIC designers won't bother to implement them all is security through "copypasting lots of code".

This is a great point. I would like to see a 100% PoS system, launched with an IPO instead of through mining. We might learn a bit from this experiment.
James Bond
Member
**
Offline Offline

Activity: 61
Merit: 10



View Profile
April 08, 2013, 01:38:57 AM
 #67

I just skimmed the whitepaper since I don't understand much of it, but I am interested in the inflation and democracy parts of it. Can you explain the inflation part to me in layman's terms?

...the chain should approach a daily amortized inflation rate of approximate 1% (Figure 1; see below) as it reaches coin year 27 or block 6,998,400. At this point, the interest rate stemming for both PoW and PoS rewards become locked in for one coin year and is then controlled by the userbase rather than being hardcoded into the chain itself. Yea or nay votes are given with each block obtained in the block header; at the end of each coin year from block 6,998,400 onwards, the sum of all votes for both PoW and PoS are tallied as yea (1) or nay (-1), summed, and divided by the total number of votes (blocks for this coin year) to yield a elected fraction v. This fraction is then the difference in inflation applied to each work system for the following coin year, with a maximum difference of 1% total.

Is that a 1% annual currency inflation rate? 1% daily would be about 3700%.

Do I understand correctly that the inflation rate can go up or down by one percentage point a year? E.g. from 1% to 2% would be the maximum change in a year?
chriswen
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500


View Profile
April 08, 2013, 01:49:52 AM
 #68

I just skimmed the whitepaper since I don't understand much of it, but I am interested in the inflation and democracy parts of it. Can you explain the inflation part to me in layman's terms?

...the chain should approach a daily amortized inflation rate of approximate 1% (Figure 1; see below) as it reaches coin year 27 or block 6,998,400. At this point, the interest rate stemming for both PoW and PoS rewards become locked in for one coin year and is then controlled by the userbase rather than being hardcoded into the chain itself. Yea or nay votes are given with each block obtained in the block header; at the end of each coin year from block 6,998,400 onwards, the sum of all votes for both PoW and PoS are tallied as yea (1) or nay (-1), summed, and divided by the total number of votes (blocks for this coin year) to yield a elected fraction v. This fraction is then the difference in inflation applied to each work system for the following coin year, with a maximum difference of 1% total.

Is that a 1% annual currency inflation rate? 1% daily would be about 3700%.

Do I understand correctly that the inflation rate can go up or down by one percentage point a year? E.g. from 1% to 2% would be the maximum change in a year?

They're's a graph in the whitepaper showing inflation rates.

Each year the inflation rate decreases by ~8%.  After 27 years the inflation rate will be 1% per year.  After year 27 voting is used to allow you to increase the inflation by up to ±1%.
James Bond
Member
**
Offline Offline

Activity: 61
Merit: 10



View Profile
April 08, 2013, 02:08:25 AM
 #69

Democracy is the original 51% attack

As you can tell, I'm not a big fan of Tyranny of the Majority. One of the advantages of bitcoin is that it reduces the ability of government/the majority to force its will on others. I don't think we should bring that back to cryptocurrencies.

Example: in 2009 in the US debtors (e.g. homeowners) would have outvoted creditors (e.g. bank owners and bondholders) and voted for inflation, transferring wealth from creditors to debtors by reducing the value of debt (being able to pay it back in less-valuable money). Maybe there would be no creditors in the first place since they realized this risk.
BubbleBoy
Sr. Member
****
Offline Offline

Activity: 504
Merit: 250



View Profile
April 08, 2013, 03:37:19 PM
 #70

Example: in 2009 in the US debtors (e.g. homeowners) would have outvoted creditors (e.g. bank owners and bondholders) and voted for inflation, transferring wealth from creditors to debtors by reducing the value of debt (being able to pay it back in less-valuable money). Maybe there would be no creditors in the first place since they realized this risk.

Yes, but do they have the stake to influence the vote ? Debitors, by definition, lack money and have little voting power. Banks, unintuitively, only have limited power because it does not make business sense to hold large reserves idle - reserves are obtained from depositors and interest must be paid. Bank depositors don't have the power either since they lost control of the base money by depositing them in a bank, and now hold a piece of paper, a  certificate of deposit that claims the bank will reimburse them with basemoney on demand. The people who have most the power to vote in such a scheme are the ones holding basemoney, coins in cold storage, current accounts, business working with allot of coins cash etc. These people have very little incentive to demand inflation, if anything the voting is pro-cyclical and will choke the money supply exactly when expansion is most necessary, during a recessionary bout.

An acceptable compromise would be a minimal expansion of 3-4% a year (the Friedman k% rule), and if a higher expansion is necessary it can be voted upon. This will insure in the worstcase a moderate stagflation.

                ████
              ▄▄████▄▄
          ▄▄████████████▄▄
       ▄██████▀▀▀▀▀▀▀▀██████▄
     ▄████▀▀            ▀▀████▄
   ▄████▀                  ▀████▄
  ▐███▀                      ▀███▌
 ▐███▀   ████▄  ████  ▄████   ▀███▌
 ████    █████▄ ████ ▄█████    ████
▐███▌    ██████▄████▄██████    ▐███▌
████     ██████████████████     ████
████     ████ ████████ ████     ████
████     ████  ██████  ████     ████
▐███▌    ████   ████   ████    ▐███▌
 ████    ████   ████   ████    ████
 ▐███▄   ████   ████   ████   ▄███▌
  ▐███▄                      ▄███▌
   ▀████▄                  ▄████▀
     ▀████▄▄            ▄▄████▀
       ▀██████▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████▀▀
              ▀▀████▀▀
                ████
MIDEX
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂ GET TOKENS ▂▂▂▂
▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂▂
BLOCKCHAIN BASED FINANCIAL PLATFORM                                # WEB ANN + Bounty <
with Licensed Exchange approved by Swiss Bankers and Lawyers           > Telegram Facebook Twitter Blog #
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 03:39:39 PM
Last edit: April 08, 2013, 03:50:46 PM by tacotime
 #71

I really don't understand the rationale behind these hybrid PoS/PoW systems. You can either solve the Byzantine consensus problem with proof of stake, or you can't. In the first case there's no need for wasteful proof of work. In the second case it makes no sense to complicate the design with something that does not add security. It's as if the designers want PoS, haven't quite figure it out how to achieve it, and add PoW for good measure just in case their PoS scheme turns out to be vacuous.

The same can be said about the baroque "polymorphic" hash. If your goal is memory hardness and a small performance opportunity for custom hardware, you should design a scheme specifically tuned for CPU implementation - if such a thing is indeed possible. A hodgepodge of all hashes under the sun while hoping the ASIC designers won't bother to implement them all is security through "copypasting lots of code".
I was really hoping there would be at least one major naysayer in this thread to think about things to improve the chain, but I'm not sure I'm following your argument.

Any solution to the byzantine consensus problem with a hybrid PoW-PoW stake system that further introduces fault-tolerance and enhances network security with no real net increase in computation power should be a better solution, not a worse one (main tradeoff is chain bloat, but I'm sure people find this acceptable).  In MC2 there are two new mechanisms of fault tolerance: (1) Multiple secure hash algorithms (2) The requirement of at least some coins (very large amounts as the chain matures) that are 90 days old in addition to 51% of the network hash rate.  The first addresses any potential failure of SHA2-256, while the second addresses double-spend attacks created by short forks of the chain.  In this way the hybrid PoW-PoS system is a better solution to the byzantine consensus problem as far as I can tell.

There's too much on the CPU that will never be used for encryption schemes for obvious reasons, such as the FPUs.  The same goes for GPUs.  Encryption algorithms need to be totally invertible, so they are forced onto the ALUs.  I'm not going to write my own secure hash algorithm when we already have several viable ones that have been poured over for years by extremely intelligent people -- it's unlikely I'm going to make one that's more secure than the ones already available.

I'm not sure I follow the "copy-pasting" argument either.  Yes, I'm adding more hash algorithms -- but there is no simple way to implement them all together with an ASIC or FPGA without using a massive number of logic units.  You're looking at maybe 35k gates with a scrypt ASIC while this would easily require 100k+ to hit all encryption algorithms.  You can tune one for just one or two of the algos, eg Chacha20-BLAKE512 and Salsa20-BLAKE512, but even attacking with a vector like that gives you 25% of the network if you had some insane amount of them; this is not enough to attack the network with a 51% attack.  Further, you have the design hassle of having to optimize for random values of N within a range of 512-2560, and you also have to do the hard hashes to determine the order and quantities for N-values for the upcoming blocks (requiring a CPU or GPU at some level in the easiest implementation).

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 03:46:57 PM
 #72

Why not create a tier system that benefits those who have little Hashing power?
With byte coin individuals ave already mined thousands of coins.
Where people with a single GPU and a hash rate of a hundred or so, suffer as they have  under 100 coins even after mining for days.

My idea is that for every additional GPU, your hashing power is reduced more and more with a tax.
What is reduced is actually sent to a community faucet. As time goes on, that tax is reduced more and more as the difficulty increases.
This tax rate is linked to your ip address,in order to stop tax evaders.

This tax also prevents the price of this new coin from imploding on day one, within hours when it first goes to market.

We also need to prevent ASIC bombing some how.
If you have an ASIC,why should we allow you to blow up the difficulty to that of Bit coin, almost over night and ruin this alt-coin?

The problem is there's no real way to determine what someone's hashing power is on the network -- they can just run 10 instances of the miner on a GPU to make it looks like their overall hashrate is lower and that they are 8 miners on a pool.  Solo mining, it's impossible.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 03:47:41 PM
 #73

Naming cryptocurrency 'coins' has bothered me - at least since the alts had a chance of fixing this.

It's the type of http://en.wikipedia.org/wiki/Skeuomorphism that may not make much sense a few years from now. And Skeumorphs are bad in general. Smiley

We should come up with a better suffix than -coin if this is an alt. Perhaps something deriving from "credits", which seems to be what most SciFi authors call future money.

Also, I like the idea here regarding reducing the massive profits of early adopters:
https://bitcointalk.org/index.php?topic=169623.0

Metacredit sounds kind of neat, I guess.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 03:53:17 PM
 #74

Added a little of potential devs and donation addresses.  If anyone may want to work on this with me, let me know.

TODO: Work out basic skeletons for additional functions that need to be implemented and create bounties for their implementation in a list in the original post.

I will not be around much for the next couple of weeks, but I will try to keep an eye on this thread and answer any questions you may have related to this chain.

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

Activity: 391
Merit: 250


View Profile
April 08, 2013, 03:55:57 PM
 #75

The one issue I have with focusing on a hashing algo that only requires CPUs is that its open to a lot of abuse my malicious actors. GPU mining discourages CPU botnets from being built, which I think is a major problem.

GPUs allow that nice median, as everyone has access to them, but are unlikely to be targeted by botnets, since some GPUs are insufficient for mining.

That's just my 2 cents. I do mine with GPUs, so I'm biased, but I see them as the nice middle ground between everyone-can-do-it and a coin being ruled by a very small group of people that invest incredible amounts of money into custom hardware.
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 03:58:29 PM
 #76

A GPU miner will probably be out sooner than later after implementation and release of this (scrypt parameters are tuned for GPU optimization over CPU optimization).

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 05:57:37 PM
 #77

chriswen brought up a problem too with whitepaper as written; I neglected to specify that network time for difficulty adjustment and reward adjustment is based solely on the PoW block height.  I will be sure to add this in in the next draft.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
twelph
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
April 08, 2013, 08:23:09 PM
 #78

Metacredit sounds kind of neat, I guess.

As cool as the sci-fi futuristic term Credit is, it still has the connotation of owing someone something. I would advise against making a drastic name change like that if you are hoping for eventual widespread adoption of the currency. Metacoin is still my first choice Smiley.

You seem to be alternating between simplifying and complicating different aspects of your design that is based on other coins. The simplification process is a step in the right direction, but I was wondering if making certain things more complex for the sake of security might cause too many unforeseen challenges early on. Have you considered staggering the implementation of certain features and security protocols as your coin progresses in usage?

Trustworthy Buyers: TTBit
tacotime (OP)
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
April 08, 2013, 08:34:27 PM
 #79

You seem to be alternating between simplifying and complicating different aspects of your design that is based on other coins. The simplification process is a step in the right direction, but I was wondering if making certain things more complex for the sake of security might cause too many unforeseen challenges early on. Have you considered staggering the implementation of certain features and security protocols as your coin progresses in usage?

I have... it depends on how big a dev team I can assemble, what the size of my donations are, and what kinds of problems we encounter when actually implementing it.  Originally I didn't have the intention of forging a new PoS system (I just had the polymorphic hash tree idea in mind for a while), but if there is added security included by using one I would definitely prefer to have it included.

In about two weeks I will also open a dev channel in freenode, and people interested can hop in and begin discussing the chain and its shortcomings, solutions to these, and so on.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
chriswen
Hero Member
*****
Offline Offline

Activity: 756
Merit: 500


View Profile
April 08, 2013, 08:38:22 PM
 #80

Also, some things have to be implemented before the launch.  It would be really hard to add security forks after the coin has been launched.
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 ... 62 »
  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!