Bitcoin Forum
June 24, 2024, 03:53:35 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Why is ECDSA needed at all?  (Read 3541 times)
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
November 03, 2016, 10:48:03 AM
 #21

Those two are very different beasts and not interchangeable.

https://www.imperialviolet.org/2013/07/18/hashsig.html
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 07, 2016, 02:57:11 PM
Last edit: November 07, 2016, 03:10:46 PM by iamnotback
Merited by ABCbits (3)
 #22

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 07, 2016, 07:54:42 PM
 #23

Merkel trees

The rapefugees had a knife to my throat. Sorry.
sidhujag
Legendary
*
Offline Offline

Activity: 2044
Merit: 1005


View Profile
November 07, 2016, 11:48:01 PM
Merited by ABCbits (1)
 #24

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.

There are many reasons why this makes sense... the generation time to create new signatures using Lamport + Merkle is negligent as that is amortized by the client which can afford the extra time for improved security. The signing is up to 10x faster but at the cost of higher bandwidth requirements like Anonymint says. However the upside is favorable as it creates a quantum resistant system that doesn't need a bunch of one way hashing to "work-around" the problem of ECDSA.

Another benefit you get from this is that Bitcoin requires one-time use addresses because those public keys once seen on the network can be used to steal balances by NSA once ECDSA is compromised so all spends with change are sent to new addresses with pubkeys not published yet. Because of this there is lack of usability on services that build upon the transaction creation process. For example in Syscoin I wanted to have an identity system (aliases) that would keep balances like accounts. To avoid mangled code to detect which addresses belong to an alias as change I simply removed the need to create new pubkeys for change and send change back to the alias pubkey which are public on the network. The multisig feature of bitcoin lacks clarity and usability because of the design of bitcoin because pubkeys cannot be published and thus redeemscripts need to be saved and sent across potentially unsafe communication lines...(read my multisig post here: http://syscoin.org/multisignature-identity-system-syscoin-2-1-technical-update/) with aliases I also save a redeem script for multisig alias identities so that any spending can be done without the need to transmit this information to each other (increases usability exponentially). The reasoning behind these changes were that if ECDSA were to be compromised Bitcoin would have a situation where they would probably fork it in as quickly as possible and choose the best implementation... leaving the need for one-time use addresses null and void which would mean my implementation which is one of simplicity actually is the optimal solution. Since I am not a cryptographer I'm not going to bother trying to change the implmentation although it shouldn't be too hard to figure out, just for lack of time to do other work but it makes total sense for long run that either Bitcoin through their new soft-fork voting mechanism or a potential coin supplanting Bitcoin would use something like this to overcome quantum computing.
funkenstein
Legendary
*
Offline Offline

Activity: 1066
Merit: 1050


Khazad ai-menu!


View Profile WWW
November 08, 2016, 01:45:54 AM
 #25

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.

Yes.  It looks like OP is suggesting a Lamport Signature coin.  Go and build it please Cheesy 

"Give me control over a coin's checkpoints and I care not who mines its blocks."
http://vtscc.org  http://woodcoin.info
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
November 08, 2016, 09:49:41 AM
Last edit: November 08, 2016, 10:33:39 AM by iamnotback
 #26

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.

There are many reasons why this makes sense... the generation time to create new signatures using Lamport + Merkle is negligent as that is amortized by the client which can afford the extra time for improved security. The signing is up to 10x faster but at the cost of higher bandwidth requirements like Anonymint says.

It is not just bandwidth, but also storage and cache coherency issues for performance. Also the performance advantage declines (is it exponentially?) as bit security increases. So eventually elliptic curves will have no (at least theoretical) resource cost disadvantages. Perhaps the one big advantage right now is (at least hypothetically although I don't know if anyone tried it) servers can employ SHA-256 ASICs for orders-of-magnitude hardware acceleration, and afaik ASICs for elliptic curve cryptography (ECC) are not mass produced.

Winternitz can compress the signatures in exchange for more computation. If the validation server-side it with SHA-256 ASICs (re-purposed Bitcoin mining hardware), it might still be much faster than unaccelerated ECC and with commensurate size at current recommended bit security levels.

However, it might limit compatible hosting for full (validating) nodes of such a design if Bitcoin mining hardware is not a standard offering.

Looking out the future 10 years when bit security levels must increase, perhaps ECC isogenies are ready for real-world usage.

However the upside is favorable as it creates a quantum resistant system that doesn't need a bunch of one way hashing to "work-around" the problem of ECDSA.

The hash of public key (to create a BTC address) to mitigate any crack on ECC seems reasonably effective, unless it can be cracked in the period of time it takes for your spend transaction to be confirmed. Combined with a Finney attack it might be theoretically vulnerable.

Another benefit you get from this is that Bitcoin requires one-time use addresses because those public keys once seen on the network can be used to steal balances by NSA once ECDSA is compromised so all spends with change are sent to new addresses with pubkeys not published yet.

Good point about why discarding public-keys on each spend are important for ECC. I had always thought (without really studying it carefully) it was for recommended for pseudo-anonymity (and perhaps some optimization of representing UXTO?), but your point is also valid.

A speculative counter-argument could posited that given widespread open-source and research sharing in today's Internet world, breakage of ECC is likely to come about in stages and so thus the improvements to ECC, so the risk of actual catastrophy is quite astronomically improbable. In other words, with so many public eyeballs looking at the issues, it is unlikely we will be publicly surprised.

So are you arguing for a persistent public-key or for not employing Merkle, so that each public-key is only (securely) one-time use?

Because of this there is lack of usability on services that build upon the transaction creation process. For example in Syscoin I wanted to have an identity system (aliases) that would keep balances like accounts. To avoid mangled code to detect which addresses belong to an alias as change I simply removed the need to create new pubkeys for change and send change back to the alias pubkey which are public on the network.

Ah I see you want the persistent public-key for a balances design to avoid the complications of a DAG-like UXTO.

But isn't there another way to make one-time spends more user-friendly wherein the published payto identity remains constant, while the current address is allowed to change. So the spending client needs to access the blockchain before signing to grab the current address for the payto identity. I guess that has a race condition though and thus I am doubting your contention that Bitcoin is aiming for one-time spend address. Rather I think they recommend retiring old publickeys for maximum security, but it is optional right? Perhaps my idea could be combined with Bitcoin's principle for a user friendly automatically secure design. On further contemplation, in an appropriate balances design the payer perhaps doesn't need to reference the current address only the payto identity. The payee can spend from the balance that exists using the current address in the blockchain for that identity. This probably has holistic interactions and ramifications, so needs to be studied carefully. Note this is roughly the design I was implementing when I paused my work to work on a new programming language.

The multisig feature of bitcoin lacks clarity and usability because of the design of bitcoin because pubkeys cannot be published and thus redeemscripts need to be saved and sent across potentially unsafe communication lines...

Interesting point that I was not aware of. I don't understand why publishing the hashes of the pub-keys is not sufficient? Are you referring to some cryptographic scheme such as where we blind who signed with a M-of-N ring signature? I haven't studied multi-sig.

(read my multisig post here: http://syscoin.org/multisignature-identity-system-syscoin-2-1-technical-update/) with aliases I also save a redeem script for multisig alias identities so that any spending can be done without the need to transmit this information to each other (increases usability exponentially). The reasoning behind these changes were that if ECDSA were to be compromised Bitcoin would have a situation where they would probably fork it in as quickly as possible and choose the best implementation... leaving the need for one-time use addresses null and void which would mean my implementation which is one of simplicity actually is the optimal solution. Since I am not a cryptographer I'm not going to bother trying to change the implmentation although it shouldn't be too hard to figure out, just for lack of time to do other work but it makes total sense for long run that either Bitcoin through their new soft-fork voting mechanism or a potential coin supplanting Bitcoin would use something like this to overcome quantum computing.

Perhaps you could rephrase that summary because I didn't grok it. But i didn't read the linked blog post yet.
funkenstein
Legendary
*
Offline Offline

Activity: 1066
Merit: 1050


Khazad ai-menu!


View Profile WWW
November 08, 2016, 09:34:02 PM
 #27

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.

There are many reasons why this makes sense... the generation time to create new signatures using Lamport + Merkle is negligent as that is amortized by the client which can afford the extra time for improved security. The signing is up to 10x faster but at the cost of higher bandwidth requirements like Anonymint says. However the upside is favorable as it creates a quantum resistant system that doesn't need a bunch of one way hashing to "work-around" the problem of ECDSA.

Another benefit you get from this is that Bitcoin requires one-time use addresses because those public keys once seen on the network can be used to steal balances by NSA once ECDSA is compromised so all spends with change are sent to new addresses with pubkeys not published yet. Because of this there is lack of usability on services that build upon the transaction creation process. For example in Syscoin I wanted to have an identity system (aliases) that would keep balances like accounts. To avoid mangled code to detect which addresses belong to an alias as change I simply removed the need to create new pubkeys for change and send change back to the alias pubkey which are public on the network. The multisig feature of bitcoin lacks clarity and usability because of the design of bitcoin because pubkeys cannot be published and thus redeemscripts need to be saved and sent across potentially unsafe communication lines...(read my multisig post here: http://syscoin.org/multisignature-identity-system-syscoin-2-1-technical-update/) with aliases I also save a redeem script for multisig alias identities so that any spending can be done without the need to transmit this information to each other (increases usability exponentially). The reasoning behind these changes were that if ECDSA were to be compromised Bitcoin would have a situation where they would probably fork it in as quickly as possible and choose the best implementation... leaving the need for one-time use addresses null and void which would mean my implementation which is one of simplicity actually is the optimal solution. Since I am not a cryptographer I'm not going to bother trying to change the implmentation although it shouldn't be too hard to figure out, just for lack of time to do other work but it makes total sense for long run that either Bitcoin through their new soft-fork voting mechanism or a potential coin supplanting Bitcoin would use something like this to overcome quantum computing.


Since you bring it up, and folks have been considering, lets look at some of the troubles. 

1)  Keys much larger.  As in 10x or more.  Blockchain bloat will be an issue if the thing becomes popular. 
2)  Lamport signatures are really use-once, because after using it once - the key is basically revealed.  So, what if you want to publish an address for donations?  Is there a way to do this?  Perhaps you could set up a way to sign a group of transactions all at once, consolidating them.  Making sure to change the address that you have published for donations first, of course.  It seems an unsolved problem still. 

Those are the big problems.  A couple of other points:

1) I'm not concerned with quantum computers, Lamport sigs is still an improved security even without that threat.  This is because they are provably as hard to crack as it is to generate a collision in the hash function being used.  ECDSA is not provably as hard as anything, always something that concerns some folks. 

2) Quantum computers allegedly could still provide a route to quicker collision finding in hash functions anyway.  Perhaps not as much of a difference as for Shor' s algo or for ECDSA, but still worth pointing out.       

"Give me control over a coin's checkpoints and I care not who mines its blocks."
http://vtscc.org  http://woodcoin.info
sidhujag
Legendary
*
Offline Offline

Activity: 2044
Merit: 1005


View Profile
November 08, 2016, 11:28:12 PM
Last edit: November 08, 2016, 11:40:13 PM by sidhujag
 #28

If my idea is worthless, then it strengthens the point why ECDSA is needed, and people will apreciate ECDSA more.

Your idea is not worthless and is already used in one of the altcoins. It's actually a nice solution for IoT-friendly cryptography for which ECDSA is too "heavy". The only requirements are to wait long enough between beginning and committing a transaction and to not reuse addresses (private keys).

Or you could use Winternitz (Lamport signatures) with Merkel trees for a more robust solution that doesn't reveal the private key and has roughly 1/20th the resource overhead (not including hardware acceleration of SHA256) of the most efficient (curve25519) elliptic curve cryptography (not factoring in batch mode). But the major downside is the size of signatures increase exponentially with increasing bit security level, which is also the problem with RSA. The theoretical gain is future quantum computing resistance, but research is proceeding on elliptic curve (isogenies) variants which are quantum computing secure.

There are many reasons why this makes sense... the generation time to create new signatures using Lamport + Merkle is negligent as that is amortized by the client which can afford the extra time for improved security. The signing is up to 10x faster but at the cost of higher bandwidth requirements like Anonymint says. However the upside is favorable as it creates a quantum resistant system that doesn't need a bunch of one way hashing to "work-around" the problem of ECDSA.

Another benefit you get from this is that Bitcoin requires one-time use addresses because those public keys once seen on the network can be used to steal balances by NSA once ECDSA is compromised so all spends with change are sent to new addresses with pubkeys not published yet. Because of this there is lack of usability on services that build upon the transaction creation process. For example in Syscoin I wanted to have an identity system (aliases) that would keep balances like accounts. To avoid mangled code to detect which addresses belong to an alias as change I simply removed the need to create new pubkeys for change and send change back to the alias pubkey which are public on the network. The multisig feature of bitcoin lacks clarity and usability because of the design of bitcoin because pubkeys cannot be published and thus redeemscripts need to be saved and sent across potentially unsafe communication lines...(read my multisig post here: http://syscoin.org/multisignature-identity-system-syscoin-2-1-technical-update/) with aliases I also save a redeem script for multisig alias identities so that any spending can be done without the need to transmit this information to each other (increases usability exponentially). The reasoning behind these changes were that if ECDSA were to be compromised Bitcoin would have a situation where they would probably fork it in as quickly as possible and choose the best implementation... leaving the need for one-time use addresses null and void which would mean my implementation which is one of simplicity actually is the optimal solution. Since I am not a cryptographer I'm not going to bother trying to change the implmentation although it shouldn't be too hard to figure out, just for lack of time to do other work but it makes total sense for long run that either Bitcoin through their new soft-fork voting mechanism or a potential coin supplanting Bitcoin would use something like this to overcome quantum computing.


Since you bring it up, and folks have been considering, lets look at some of the troubles.  

1)  Keys much larger.  As in 10x or more.  Blockchain bloat will be an issue if the thing becomes popular.  
2)  Lamport signatures are really use-once, because after using it once - the key is basically revealed.  So, what if you want to publish an address for donations?  Is there a way to do this?  Perhaps you could set up a way to sign a group of transactions all at once, consolidating them.  Making sure to change the address that you have published for donations first, of course.  It seems an unsolved problem still.  

Those are the big problems.  A couple of other points:

1) I'm not concerned with quantum computers, Lamport sigs is still an improved security even without that threat.  This is because they are provably as hard to crack as it is to generate a collision in the hash function being used.  ECDSA is not provably as hard as anything, always something that concerns some folks.  

2) Quantum computers allegedly could still provide a route to quicker collision finding in hash functions anyway.  Perhaps not as much of a difference as for Shor' s algo or for ECDSA, but still worth pointing out.        

1) keys are larger but no need to do bunch of one way hashes, just work on the pubkeys and publish those pubkeys. Bloat may be an issue because bandwidth cost is higher but you do get faster signing, so overall you may sync faster.. 20x more per sig for storage and bandwidth costs which sucks, but you don't have the need for change addresses(1 less vout) and other tradeoffs that make end user and integrations much nicer and easier to use. You don't even need to fully spend an input.

2) The Merkle Signature Scheme, which I was advocating for, combines the one-time signature scheme (either Lamport or Winternitz) with a Merkle tree. This allows us to use one public key to sign many messages without worrying about compromising security.  No need for one way hashing scheme to create 160 or even 58 addresses, unless there is analysis to show that the bandwidth cost savings is higher than the cpu and ram usage to do those calculations per tx, based on some metrics.
Ill respond to anonymity later when I have some more time away from coding.

Bitcoin as is is already quantum resistant, its just that its not as nice as it could be with a different signing algo, although at the cost of bandwidth (these are value added tradeoffs in my mind), and since I can see Bitcoin is already going to switch one way or another when NSA does break ECDSA then for me I've already started coding around that assumption in my project by discarding the convention of using one-time addresses only and allowing me to create a fully functional multisig identity system with balances.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1009

Newbie


View Profile
November 09, 2016, 07:33:48 AM
 #29

2) Quantum computers allegedly could still provide a route to quicker collision finding in hash functions anyway.  Perhaps not as much of a difference as for Shor' s algo or for ECDSA, but still worth pointing out.       

Use 384-bit hashing, a QC will need 2^192 operations to crack it (subject to P=NP problem).
funkenstein
Legendary
*
Offline Offline

Activity: 1066
Merit: 1050


Khazad ai-menu!


View Profile WWW
November 10, 2016, 07:01:43 AM
 #30


...I've already started coding around that assumption in my project by discarding the convention of using one-time addresses only and allowing me to create a fully functional multisig identity system with balances.


This sounds really interesting.  Looking forward to see Smiley  good luck! 

"Give me control over a coin's checkpoints and I care not who mines its blocks."
http://vtscc.org  http://woodcoin.info
FruitBucket
Sr. Member
****
Offline Offline

Activity: 286
Merit: 250



View Profile
November 11, 2016, 06:47:29 PM
 #31

If someone doesn't understand why mining and ECDSA signatures are part of that solution (or even what makes something a "public key" or "private key", and comes in with "Lets get rid of ECDSA and use SHA256 to prove authorized access to bitcoins!", they are wasting their own time, and the time of every person that accidentally reads their post.  I'm not going to waste time explaining all the many technical details to someone that is clearly more interested in announcing their amazing discovery than trying to learn.

I think we should give this guy a chance and proof him wrong.

This may sound silly or even genius, and I am not a big expert or cryptographer, but as I look at it, the public->private key system is 1 directional, so why do we need to use ECDSA when we could just use a SHA-256 instead or something like that. Lemme explain my theory, how we could make a blockchain without ECDSA:


  • Private key generated with RNG, then hashed with SHA256, the SHA256 hash , this would be the pubkey, and a Base58encoded checksumed version would be the bitcoin address
  • Bitcoin address and bitcoin private key included in blockchain at spending, so miners can verify the owner without the need for asymmetric cryptography, the private key would be revealed when you send money to a new address, so this way addresses will be forcibly reused, and would no longer serve as "accounts" but only as a receipt of transaction
  • The public key would be sent first ,and after 6 confirmations, the private key is sent, this would ensure that nodes/miner cant steal/double spend the coin. The pubkey gets indexed in the blockchain, after 6 confirm the private key gets indexed too ,and after another 6 confirm the transaction is finalized
  • If nodes/miners reject the public key and is not included in the blockchain, then the user would not send out the private key (the private key revelation is the finalization of the transaction)
  • The change would be sent back to the owner's change address, fee sent to miners, and the sum sent to the destination address
  • Mining protocol not affected
  • A lot of unnecessary work would be eliminated for both nodes and miners
  • More efficient cryptocurrency model
  • When you would sign a message with the address, it would automatically send the money from that address to a new address of yours, so that a message signing would still prove that you own that address, but the money need to be sent to a change address to ensure that the verifier doesnt stea it
  • Ultra secure, quantum secure, since we would no longer be constrained by a 128 bit private key, but by even a 1000 bit key by using numbers, letters, special characters to generate the private key, it would be way more secure

What do you think of my idea? Did Satoshi miss this thought?

You are saying that you would wait for 6 confirmations and then send the private key. However, anyone could just pretend to own the private key while the network cannot verify that you own the private key. This means that it did not matter how many confirmations you have waited as your transactions only becomes worthy once it can be verified (in your case once your private key is revealed).
As such, problems arise which others have described.

Scenario 1:
Mallory sends 1 BTC from Alice address. Mallory is an attacker and actually do not control Alice address (private key) but I can still make the transaction as the pub key is visible e.g. base64decode address. After 6 confirmations Mallory is doing nothing. I suppose in your example you would probably state that the transaction becomes invalid after e.g. 12 transactions without revealing the pubkey, which is fine - no funds are lost for Alice in this example, but way lay the groundwork for the next.

Scenario 2:
Alice sends 1 BTC to Bob (Transaction 1). Transaction 2: Mallory impersonates Alice (can be easily done as per Scenario 1) and send 1 BTC to himself. After 6 confirmations Alice reveals her private key. Meanwhile Mallory established a Man-In-The-Middle between Alice and himself. Mallory does not forward the private key to the network for Transaction 1, instead Mallory will forward the private key of Alice to the network for Transaction 2. Since there is no signing in you scheme this can easily be done. Mallory will continue to block Alice until e.g. 12 transactions as per Scenario 1. After this point all funds are forever lost for Alice.

Pages: « 1 [2]  All
  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!