Bitcoin Forum
July 05, 2024, 04:27:46 PM *
News: Latest Bitcoin Core release: 27.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 »
  Print  
Author Topic: [ANN] eMunie (EMU) - NOT a BitCoin fork/clone - call for beta testers  (Read 78365 times)
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 08:33:31 PM
 #241


A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

What about a "unique node list"? As employed by Ripple.

https://ripple.com/wiki/Unique_Node_List

I'm also thinking there must be a way to mathematically achieve "proof-of-verification", ie. a type of proof-of-work that is less random, and has more utility toward making the system honest. ie. the work done to verify a set of transactions results in a mathematical proof/signature, that can be verified by other nodes. If one of the nodes finds out that you did not do the work (ie. tracing the transactions to that point shows an invalid transaction, or mathematical derivation is incorrect), then your node gets penalized or ignored.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
TCPC
Newbie
*
Offline Offline

Activity: 33
Merit: 0


View Profile
May 31, 2013, 08:34:02 PM
 #242

I am interested.  I would be happy to help beta test.
Fuserleer (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1016



View Profile WWW
May 31, 2013, 08:45:45 PM
 #243


A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

What about a "unique node list"? As employed by Ripple.

https://ripple.com/wiki/Unique_Node_List

I'm also thinking there must be a way to mathematically achieve "proof-of-verification", ie. a type of proof-of-work that is less random, and has more utility toward making the system honest. ie. the work done to verify a set of transactions results in a mathematical proof/signature, that can be verified by other nodes. If one of the nodes finds out that you did not do the work (ie. tracing the transactions to that point shows an invalid transaction, or mathematical derivation is incorrect), then your node gets penalized or ignored.

That's precisely what our method attempts to achieve.

There seems to be some stigma about the method we are developing, but I haven't at one point said that it's unbreakable, it is, IF you have enough resources to pull it off.  What our algorithm and network architecture should achieve (and we'll soon see if it really does in the beta) is more resiliance. 

The network as a whole trades some efficiency for security of verifying the transactions almost exactly as you state.

Lots of new posts in here today, so I'll trawl through and pick out any other interesting ones and reply over the course of the evening.

JDDev
Full Member
***
Offline Offline

Activity: 162
Merit: 100


View Profile
May 31, 2013, 08:51:21 PM
 #244

I'd like to be a tester as well, sounds interesting
cryptohunter
Legendary
*
Offline Offline

Activity: 2100
Merit: 1167

MY RED TRUST LEFT BY SCUMBAGS - READ MY SIG


View Profile
May 31, 2013, 09:19:25 PM
 #245

i'll help with the beta testing

serge79
Full Member
***
Offline Offline

Activity: 154
Merit: 100



View Profile
May 31, 2013, 09:49:01 PM
 #246

I'd like to be a beta tester as well.
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
May 31, 2013, 10:18:32 PM
 #247


A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend.  I do not see any new solution to the Byzantine Generals problem in your answers.

What about a "unique node list"? As employed by Ripple.

https://ripple.com/wiki/Unique_Node_List

This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 10:32:41 PM
 #248


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
k0vic
Member
**
Offline Offline

Activity: 113
Merit: 10



View Profile
May 31, 2013, 10:35:05 PM
 #249

I sent a PM when you guys first announced cause I couldn't post yet. Please include me if there is still room, I think you guys have some good thoughts!

LTC- LKNm2UVuBgMLJNPU7pV5cgQnGx6PWGk7Ju
BTC- 1NHcECfk8oxJe83m9bPME2cdUCY72vuA2Y
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 10:35:19 PM
 #250


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

Although, I think this is theoretically possible, I'm still waiting to see the math... I look forward to reading the source.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
May 31, 2013, 10:42:09 PM
 #251


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

This amounts to executing messengers who are found to be fraudulent.  A rouge general can still spawn an infinite number of messengers.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 10:45:35 PM
 #252


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

Although, I think this is theoretically possible, I'm still waiting to see the math... I look forward to reading the source.

You see, Bitcoin works off the ability of being able to prove that a certain amount of work was done. This allows the system to decide who next gets the privilege of writing the next block of transactions; and therefore evenly distribute power based on work... but what if you could not only prove work was done, but also prove that a specific form of work was done? This would allow you to not only coerce the network into doing work, but doing work toward a specific end goal, so it would lead to a more efficient system. If you try to do a Sybil attack, you would have to do this verifiable work or the clients would all ignore your contributed transactions.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
May 31, 2013, 10:52:11 PM
 #253

How is the work getting more specific?  I don't understand.  This sounds like the "why don't we use bitcoin mining to do something useful like search for extraterrestrial life" argument.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
xorxor
Sr. Member
****
Offline Offline

Activity: 476
Merit: 253



View Profile
May 31, 2013, 11:37:30 PM
 #254

How do you force people to choose their hatchery randomly? Is there anything to be gained from choosing a hatchery on purpose instead of randomly?

The hatcher that is selected and the vote (yes or no) are handled by the client software.  The actual wallet holder has no control over this at all.

If you were to grab the source and modify it to always vote yes, then even if there were only 100 other voters in the system, you vote can only skew the vote by 1%, which isn't enough to cause damage and will only push up the vote threshold over time.

there are guys having tens of VPS's with  8 cores and VM capability, raping every new coin, or simply mining YAC.
VPS'es are easy and cheap to obtain. installing numerous VM's with a client's on every one of them is easy and fast.
there would be a monstrous fight for getting a bigger and bigger amount of clients and hatchers, sending EMU from one to another to make a lot of transactions and confirmations - and therefore the bigest posible percentage of new EMU creation. this means, NO ONE ELSE would get anything - just like trying to solomine BTC on cpu right now.

difference:
 POW - waste a lot of energy

 distributed trust - waste a lot of energy, bandwidth, transaction history data.

this is possible even when source will NOT be given, or system was perfect in other ways.
 

to be secure, it has to be ripple-like closed and centralised, and thats no crypto currency, thats company issued credit.

please tell me where am I wrong.

fuck deeponion, fuck bitcoincash, all glory to one BITCOIN
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 11:41:35 PM
 #255


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

This amounts to executing messengers who are found to be fraudulent.  A rouge general can still spawn an infinite number of messengers.

In bitcoin, every client must determine which blockchain required the most work to produce. The infinite messengers must do more work than the rest of the network to get its blockchain accepted. In the case of emula, the client must also decide on which transactions are the true ones, so there needs to be a way the client can determine which set of transactions required the most verification work to produce.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
timeofmind
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 31, 2013, 11:47:02 PM
 #256

How is the work getting more specific?  I don't understand.  This sounds like the "why don't we use bitcoin mining to do something useful like search for extraterrestrial life" argument.

ya. Problem with that is that it is difficult to verify that the work was done searching for "extra terrestrial life". It requires just as much work to verify that this was done, as is required to do it. In the case of Bitcoin, it takes an insignificant amount of work to verify that a  large amount of work was done. But if you had a way to mathematically verify that a certain type of work was done, and you could verify that that work was done using much less work that was required to do that verification, then in fact, you could achieve a system where you could force the miners to do specific work. ie. the client simply rejects transactions or blocks of transactions that can be mathematically disproven to have done that specific work, and also only accepts the transaction chain that has done the most work.

BitMessage: BM-GtUdgmqs5voD3M6o3X38gM93RyxPhDK9
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
June 01, 2013, 12:17:43 AM
 #257


This Quora answer describes the Byzantine General's problem well:

Quote
The Byzantine Generals' Problem roughly goes as follows: N Generals have their armies camped outside a city they want to invade. They know their numbers are strong enough that if at least 1/2 of them attack at the same time they'll be victorious. But if they don't coordinate the time of attack, they'll be spread too thin and all die. They also suspect that some of the Generals might be disloyal and send fake messages. Since they can only communicate by messenger, they have no means to verify the authenticity of a message. How can such a large group reach consensus on the time of attack without trust or a central authority, especially when faced with adversaries intent on confusing them?
http://www.quora.com/Bitcoin/Is-the-cryptocurrency-Bitcoin-a-good-idea

Obviously if you change the problem so that generals can trust certain other generals or messengers or outside "unique nodes", you can "solve" it.  This is how banks and ripple solve it.  Bitcoin's breakthrough was solving the problem with no trust by using a proof-of-work system.  If a coin does not use POW, that means that there is centralization/trust involved.  Emulah doesn't seem to understand this concept very well.

You did not even comment on the mechanism that Emulah claims to use above (ie. proof-of-work-of-verification). ie. Emulah attempts to rely on proof-of-work. The proof is just different from hashcash. ie. Emulah is using something different from hashcash to prove that work was done. Bitcoin and all other alts rely on the hashcash concept.

This amounts to executing messengers who are found to be fraudulent.  A rouge general can still spawn an infinite number of messengers.

In bitcoin, every client must determine which blockchain required the most work to produce. The infinite messengers must do more work than the rest of the network to get its blockchain accepted. In the case of emula, the client must also decide on which transactions are the true ones, so there needs to be a way the client can determine which set of transactions required the most verification work to produce.

In Emula, there is no proof-of-work getting done by the generals, so all that can be verified is the existence of messengers and whatever random messages they want to make up.  Emula seems to be taking the existence of a messenger as one vote, which is stupid.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
Fuserleer (OP)
Legendary
*
Offline Offline

Activity: 1064
Merit: 1016



View Profile WWW
June 01, 2013, 12:31:59 AM
 #258

How do you force people to choose their hatchery randomly? Is there anything to be gained from choosing a hatchery on purpose instead of randomly?

The hatcher that is selected and the vote (yes or no) are handled by the client software.  The actual wallet holder has no control over this at all.

If you were to grab the source and modify it to always vote yes, then even if there were only 100 other voters in the system, you vote can only skew the vote by 1%, which isn't enough to cause damage and will only push up the vote threshold over time.

there are guys having tens of VPS's with  8 cores and VM capability, raping every new coin, or simply mining YAC.
VPS'es are easy and cheap to obtain. installing numerous VM's with a client's on every one of them is easy and fast.
there would be a monstrous fight for getting a bigger and bigger amount of clients and hatchers, sending EMU from one to another to make a lot of transactions and confirmations - and therefore the bigest posible percentage of new EMU creation. this means, NO ONE ELSE would get anything - just like trying to solomine BTC on cpu right now.

difference:
 POW - waste a lot of energy

 distributed trust - waste a lot of energy, bandwidth, transaction history data.

this is possible even when source will NOT be given, or system was perfect in other ways.
 

to be secure, it has to be ripple-like closed and centralised, and thats no crypto currency, thats company issued credit.

please tell me where am I wrong.

OK I've written a lot on this already, but I'll try and re-explain to clear up the confusion.

100 nodes in the system, 49 honest, 51 not.

2 are hatchers, 1 honest, 1 not.  Both do equal transaction according to honest/dishonest nodes in the system (49% and 51% respectively) work for arguments sake.

Honest nodes vote honest hatcher to make an EMU
Honest hatcher creates EMU and distributes 39% to itself, and 41% to dishonest hatcher.  Remaining 20% is distributed to non-hatcher nodes dependent on EMU holding.
Everyones happy.

Dishonest node votes yes to EMU create with dishonest clients.
Dishonest node creates EMU
Dishonest node gives all EMU to itself.

Honest nodes reject dishonest nodes EMU creation.  
Dishonest node can't spend those EMU's in system.
Honest nodes happy again.
Dishonest node wasted effort.

EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.  Thus, there's no point in dishonest nodes trying to create EMU's for themselves as they can not keep them, and if they do, the honest nodes reject them and they can never be spent.


mercSuey
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
June 01, 2013, 12:45:20 AM
 #259

Quote
Currency generation is a collaborative effort between n-client nodes and a hatching node.  Each node in the system will cast a vote to a random hatching node to whether to create a currency unit (EMU).  Creation volume of currency over time is confined to a specified target interval to maintain a steady flow of new EMU's.  As the hatching nodes have the information available of all newly created EMU's, they are able to select the correct vote threshold for the generation of new EMU's.  If the collective vote is a success a number of EMU units are created and are distributed around the system in the following manner:

How will each node be represented in the network?  Is it a dynamic id assigned with each connection to the network?  Is it based on client id?  If so, can I have multiple instances open on one computer?  If not, can I benefit by having many clients open on multiple computers?  Obviously, the algo which randomly chooses a node to cast a vote is important.  But can a node know when it has received a vote to create an EMU?  If so, because it's safe to assume the probability of receiving two (or N) consecutive votes is 'lower' than receiving a new vote, can I benefit somehow by closing my client and reconnecting to the network either with the same client or a different one (this question is related to how nodes will be represented in the network)?  At first glance, given enough bandwidth (Google's 1 Gb/s fiber internet service, for example) and computing power to quickly reconnect with the network, if nodes' identification are dynamic, it seems I can exploit the EMU voting system (and gain more interest as well).  If nodes' id are static, then that makes the network more vulnerable.  Obviously, I'm just hand-waving until I see the actual algo/code.  

EDIT:  Seems like posts were added with similar ideas while I was typing...
Seth Otterstad
Sr. Member
****
Offline Offline

Activity: 328
Merit: 250



View Profile
June 01, 2013, 12:59:21 AM
 #260

OK I've written a lot on this already, but I'll try and re-explain to clear up the confusion.

100 nodes in the system, 49 honest, 51 not.

2 are hatchers, 1 honest, 1 not.  Both do equal transaction according to honest/dishonest nodes in the system (49% and 51% respectively) work for arguments sake.

Honest nodes vote honest hatcher to make an EMU
Honest hatcher creates EMU and distributes 39% to itself, and 41% to dishonest hatcher.  Remaining 20% is distributed to non-hatcher nodes dependent on EMU holding.
Everyones happy.

Dishonest node votes yes to EMU create with dishonest clients.
Dishonest node creates EMU
Dishonest node gives all EMU to itself.

Honest nodes reject dishonest nodes EMU creation.  
Dishonest node can't spend those EMU's in system.
Honest nodes happy again.
Dishonest node wasted effort.

EMU's HAVE to be distrubuted according to set of rules, which can be checked against the ledger by ANY node in the system.  Thus, there's no point in dishonest nodes trying to create EMU's for themselves as they can not keep them, and if they do, the honest nodes reject them and they can never be spent.
Everyone is not happy when 41% of the EMU is distributed to one guy because he is running 51 dishonest nodes on amazon servers.

You haven't even bothered to address how you plan to prevent double spending or network transaction blocking by a guy running 51% of the clients on amazon servers.

Seth Otterstad's Blog          @SethOtterstad on twitter          Seth on google+
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 »
  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!