Bitcoin Forum
December 14, 2017, 11:10:25 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Where would you prefer the VRC/VRM exchange pair be?
Bittrex
Poloniex
Both
Other

Pages: « 1 ... 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [91] 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 ... 964 »
  Print  
Author Topic: [ANN][VRC] VeriCoin Proof of Stake-Time Currency | New Roadmap Released  (Read 1346435 times)
battbot
Hero Member
*****
Offline Offline

Activity: 560



View Profile
June 06, 2014, 05:28:50 AM
 #1801

Since CRY was so nice to accuse us of stealing ANON from others and saying how theirs is better, I figured I would write a quick analysis on theirs.

Firstly, I love their stick figures.

Anyway, their implementation is not possible.

Let's go through their list point by point (my commentary in bold):

CryptCast Synopsis
● Wallet A wants to send an anonymous transaction to Wallet B.
● Wallet A (sender) encrypts a message towards Wallet B (recipient) by
using private/public key concept, with Wallet B’s public key.
I'm not sure if CRY is talking about using the CRY public/private keys as in addresses and private keys, but I looked very heavily into that and it's not possible. The pubkey (or address) is actually a hash of the privatekey and cannot serve as a private key. It's possible to get Wallet B's public key, but only if it has sent a transaction before and thus it's in the blockchain. There's no transmission system to send that public key.
● The message is broadcasted through the nodes connected to Wallet A, and
will reach will reach Wallet B via the broadcasting system that already
exists in the Bitcoin protocol.
What I presume CRY is discussing here is probably the OP_RETURN function being integrated into BitCoin right now. It is not in the CRY codebase and is tough to integrate. More importantly, it only can store 40 bytes of data: https://bitsharestalk.org/index.php?topic=3830.0. That is not close to enough to do what is being proposed.
● Wallet B is the only one that can decrypt the message with Wallet B’s
private key.
● Wallet B receives the request for secure transaction from Wallet A.
There is no mention of how this will be done and is not easily done.
● The message contains the total number of transactions that are capable
of transmitting, and the total amount of coins.
I'm surprised there are no checksums, address verification, etc.
● E.g., if Wallet A wishes to send 3 transactions and Wallet B accepts it,
it returns 3 new addresses (encrypted message with pubkey of wallet A.)
As I said before, this is not possible to send in 40 bytes. Not only that, but where is the pubkey of wallet A going to come from?
● The message is again broadcasted till it reaches wallet A.
Broadcast until it reaches? What if Wallet A is turned off? How does it stop wallet B from broadcasting? Is there an ack? Otherwise this is certainly going to flood the blockchain. Can someone say 1 TB drives for a coin wallet?
● Wallet A decrypts the message, receives the new addresses and creates 3
transactions for each IN transaction it has, sending them to each new
address it got from the new wallet.
● Multi-transaction time-delay will be optional for maximum anonymity if
speed is not required.
● If Wallet B does not accept any type of secure transaction, it encrypts
again a message with decline response
● Wallet A then has the option of sending plain, non-secure transaction,
or to not send it at all.

I got tired of analyzing more but frankly this is impossible to do without completely restructuring the blockchain and requiring a very serious hard fork.

RE: Cryptcoin Anonymous Sending

We will have full answers to your questions tomorrow, things are busy right now.

We have this working right now in testing and there are solutions to all of these issues. It explicitly says in the paper that it isn't a complete explanation. and yes, we will be doing a hard forking.

It is a very interesting method of anon sending, and we will be open sourcing it eventually, also.

It's funny that nobody in the crypto community realizes that every method of "anonymous" sending is just a proxied mixer setup which was implemented by fedoracoin all the way back in February. But nobody cared about fedoracoin.  All the current implementations are merely centralized mixers, with everyone racing to this same solution. CRY is looking forward to new things.

So far we have met all our promises. We will give more through explanations in the coming day or two - it is a busy time.

Shouldn't you be working on your own "anon" features?  Smiley


Let's get our facts straight here -- XC has already implemented xnodes which offers a 100% decentralized solution.  

XCurrency www.xc-official.com #xcofficial
XChat: XFCe4ue7yCeSvn22gisLXdfd9HhdVfr5uJ / 28VjdNMZMyF6UiHRqkSCi63UikfcdHXj8nRzhkb9GmHip
1513249825
Hero Member
*
Offline Offline

Posts: 1513249825

View Profile Personal Message (Offline)

Ignore
1513249825
Reply with quote  #2

1513249825
Report to moderator
1513249825
Hero Member
*
Offline Offline

Posts: 1513249825

View Profile Personal Message (Offline)

Ignore
1513249825
Reply with quote  #2

1513249825
Report to moderator
1513249825
Hero Member
*
Offline Offline

Posts: 1513249825

View Profile Personal Message (Offline)

Ignore
1513249825
Reply with quote  #2

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

Posts: 1513249825

View Profile Personal Message (Offline)

Ignore
1513249825
Reply with quote  #2

1513249825
Report to moderator
cyberhacker
Legendary
*
Offline Offline

Activity: 1134



View Profile WWW
June 06, 2014, 05:30:04 AM
 #1802

什么情况? 我早上买的时候  2014-06-05 22:44:53   BUY   0.00012220
               现在的价格2014-06-06 05:17:17   BUY   0.00007600
     在搞什么啊?这是要害死人的啊~~~· Cry


sell your holdings right now Smiley

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
ccryptcoin
Member
**
Offline Offline

Activity: 92

CRYPT Developer


View Profile WWW
June 06, 2014, 05:35:00 AM
 #1803

Since CRY was so nice to accuse us of stealing ANON from others and saying how theirs is better, I figured I would write a quick analysis on theirs.

Firstly, I love their stick figures.

Anyway, their implementation is not possible.

Let's go through their list point by point (my commentary in bold):

CryptCast Synopsis
● Wallet A wants to send an anonymous transaction to Wallet B.
● Wallet A (sender) encrypts a message towards Wallet B (recipient) by
using private/public key concept, with Wallet B’s public key.
I'm not sure if CRY is talking about using the CRY public/private keys as in addresses and private keys, but I looked very heavily into that and it's not possible. The pubkey (or address) is actually a hash of the privatekey and cannot serve as a private key. It's possible to get Wallet B's public key, but only if it has sent a transaction before and thus it's in the blockchain. There's no transmission system to send that public key.
● The message is broadcasted through the nodes connected to Wallet A, and
will reach will reach Wallet B via the broadcasting system that already
exists in the Bitcoin protocol.
What I presume CRY is discussing here is probably the OP_RETURN function being integrated into BitCoin right now. It is not in the CRY codebase and is tough to integrate. More importantly, it only can store 40 bytes of data: https://bitsharestalk.org/index.php?topic=3830.0. That is not close to enough to do what is being proposed.
● Wallet B is the only one that can decrypt the message with Wallet B’s
private key.
● Wallet B receives the request for secure transaction from Wallet A.
There is no mention of how this will be done and is not easily done.
● The message contains the total number of transactions that are capable
of transmitting, and the total amount of coins.
I'm surprised there are no checksums, address verification, etc.
● E.g., if Wallet A wishes to send 3 transactions and Wallet B accepts it,
it returns 3 new addresses (encrypted message with pubkey of wallet A.)
As I said before, this is not possible to send in 40 bytes. Not only that, but where is the pubkey of wallet A going to come from?
● The message is again broadcasted till it reaches wallet A.
Broadcast until it reaches? What if Wallet A is turned off? How does it stop wallet B from broadcasting? Is there an ack? Otherwise this is certainly going to flood the blockchain. Can someone say 1 TB drives for a coin wallet?
● Wallet A decrypts the message, receives the new addresses and creates 3
transactions for each IN transaction it has, sending them to each new
address it got from the new wallet.
● Multi-transaction time-delay will be optional for maximum anonymity if
speed is not required.
● If Wallet B does not accept any type of secure transaction, it encrypts
again a message with decline response
● Wallet A then has the option of sending plain, non-secure transaction,
or to not send it at all.

I got tired of analyzing more but frankly this is impossible to do without completely restructuring the blockchain and requiring a very serious hard fork.

We will have full answers to your questions tomorrow, things are busy right now.

We have this working right now in testing and there are solutions to all of these issues. It explicitly says in the paper that it isn't a complete explanation. and yes, we will be doing a hard forking.

It is a very interesting method of anon sending, and we will be open sourcing it eventually, also.

It's funny that nobody in the crypto community realizes that every method of "anonymous" sending is just a proxied mixer setup which was implemented by fedoracoin all the way back in February. But nobody cared about fedoracoin.  All the current implementations are merely centralized mixers, with everyone racing to this same solution. CRY is looking forward to new things.

So far we have met all our promises. We will give more through explanations in the coming day or two - it is a busy time.

Shouldn't you be working on your own "anon" features?  Smiley


There's no "truely anon" anon, just like there's no "perfect" passwords. With enough computing power you can crack anything. And that includes a decentralized system. Anyway I look forward to it. I'm happy to discuss privately if you'd like. We had a short term VRC testnet with a different merkel hash where we tested trying to send encrypted data via the message tx values but it was impossible to have efficient sends/receives. But please, before you release more details, feel free to PM me. I won't leak anything and will let you know what I think if you're interested.

SMS wallet is our top priority right now but yes we are working on our own anon features.


I was disturbed because you posted friendly message in CRY thread:

"Quote from: pnosker on Today at 05:11:57 AM
Nice paper. Want to PM me and I can discuss it with you? We looked into doing it the way you're planning and I might be able to help."


But then made very bad comments in your thread. This is not proper, and I am wary to discuss plans with you. Yes, there are some things being ironed out. But the feature is working and we are moving forward with our method at a steady pace. At the very worst, we would implement the node/mixer tech which is very simple. But we prefer to do a New type of anon send.

I wish you luck with your project, and I know we will be watching each others progress Smiley

Lead Dev of CRYPT -- http://www.cryptco.org/ -- @CryptCoinTeam
tristartek
Full Member
***
Offline Offline

Activity: 140


View Profile
June 06, 2014, 05:36:28 AM
 #1804

Since CRY was so nice to accuse us of stealing ANON from others and saying how theirs is better, I figured I would write a quick analysis on theirs.

Firstly, I love their stick figures.

Anyway, their implementation is not possible.

Let's go through their list point by point (my commentary in bold):

CryptCast Synopsis
● Wallet A wants to send an anonymous transaction to Wallet B.
● Wallet A (sender) encrypts a message towards Wallet B (recipient) by
using private/public key concept, with Wallet B’s public key.
I'm not sure if CRY is talking about using the CRY public/private keys as in addresses and private keys, but I looked very heavily into that and it's not possible. The pubkey (or address) is actually a hash of the privatekey and cannot serve as a private key. It's possible to get Wallet B's public key, but only if it has sent a transaction before and thus it's in the blockchain. There's no transmission system to send that public key.
● The message is broadcasted through the nodes connected to Wallet A, and
will reach will reach Wallet B via the broadcasting system that already
exists in the Bitcoin protocol.
What I presume CRY is discussing here is probably the OP_RETURN function being integrated into BitCoin right now. It is not in the CRY codebase and is tough to integrate. More importantly, it only can store 40 bytes of data: https://bitsharestalk.org/index.php?topic=3830.0. That is not close to enough to do what is being proposed.
● Wallet B is the only one that can decrypt the message with Wallet B’s
private key.
● Wallet B receives the request for secure transaction from Wallet A.
There is no mention of how this will be done and is not easily done.
● The message contains the total number of transactions that are capable
of transmitting, and the total amount of coins.
I'm surprised there are no checksums, address verification, etc.
● E.g., if Wallet A wishes to send 3 transactions and Wallet B accepts it,
it returns 3 new addresses (encrypted message with pubkey of wallet A.)
As I said before, this is not possible to send in 40 bytes. Not only that, but where is the pubkey of wallet A going to come from?
● The message is again broadcasted till it reaches wallet A.
Broadcast until it reaches? What if Wallet A is turned off? How does it stop wallet B from broadcasting? Is there an ack? Otherwise this is certainly going to flood the blockchain. Can someone say 1 TB drives for a coin wallet?
● Wallet A decrypts the message, receives the new addresses and creates 3
transactions for each IN transaction it has, sending them to each new
address it got from the new wallet.
● Multi-transaction time-delay will be optional for maximum anonymity if
speed is not required.
● If Wallet B does not accept any type of secure transaction, it encrypts
again a message with decline response
● Wallet A then has the option of sending plain, non-secure transaction,
or to not send it at all.

I got tired of analyzing more but frankly this is impossible to do without completely restructuring the blockchain and requiring a very serious hard fork.

But isn't VRC just a mixer?  Its still centralized and traceable.

BTC: 1KTg6RkiHjovXqVfVB1a74NPPXLnoL1HNf
MrWHALE
Jr. Member
*
Offline Offline

Activity: 56


View Profile
June 06, 2014, 05:37:13 AM
 #1805

rofl, CRY's whitepaper is such a piece of shit.  Evidence of a total scam -- they can't even make a proper whitepaper.
pnosker
Sr. Member
****
Offline Offline

Activity: 462


View Profile
June 06, 2014, 05:44:12 AM
 #1806

Since CRY was so nice to accuse us of stealing ANON from others and saying how theirs is better, I figured I would write a quick analysis on theirs.

Firstly, I love their stick figures.

Anyway, their implementation is not possible.

Let's go through their list point by point (my commentary in bold):

CryptCast Synopsis
● Wallet A wants to send an anonymous transaction to Wallet B.
● Wallet A (sender) encrypts a message towards Wallet B (recipient) by
using private/public key concept, with Wallet B’s public key.
I'm not sure if CRY is talking about using the CRY public/private keys as in addresses and private keys, but I looked very heavily into that and it's not possible. The pubkey (or address) is actually a hash of the privatekey and cannot serve as a private key. It's possible to get Wallet B's public key, but only if it has sent a transaction before and thus it's in the blockchain. There's no transmission system to send that public key.
● The message is broadcasted through the nodes connected to Wallet A, and
will reach will reach Wallet B via the broadcasting system that already
exists in the Bitcoin protocol.
What I presume CRY is discussing here is probably the OP_RETURN function being integrated into BitCoin right now. It is not in the CRY codebase and is tough to integrate. More importantly, it only can store 40 bytes of data: https://bitsharestalk.org/index.php?topic=3830.0. That is not close to enough to do what is being proposed.
● Wallet B is the only one that can decrypt the message with Wallet B’s
private key.
● Wallet B receives the request for secure transaction from Wallet A.
There is no mention of how this will be done and is not easily done.
● The message contains the total number of transactions that are capable
of transmitting, and the total amount of coins.
I'm surprised there are no checksums, address verification, etc.
● E.g., if Wallet A wishes to send 3 transactions and Wallet B accepts it,
it returns 3 new addresses (encrypted message with pubkey of wallet A.)
As I said before, this is not possible to send in 40 bytes. Not only that, but where is the pubkey of wallet A going to come from?
● The message is again broadcasted till it reaches wallet A.
Broadcast until it reaches? What if Wallet A is turned off? How does it stop wallet B from broadcasting? Is there an ack? Otherwise this is certainly going to flood the blockchain. Can someone say 1 TB drives for a coin wallet?
● Wallet A decrypts the message, receives the new addresses and creates 3
transactions for each IN transaction it has, sending them to each new
address it got from the new wallet.
● Multi-transaction time-delay will be optional for maximum anonymity if
speed is not required.
● If Wallet B does not accept any type of secure transaction, it encrypts
again a message with decline response
● Wallet A then has the option of sending plain, non-secure transaction,
or to not send it at all.

I got tired of analyzing more but frankly this is impossible to do without completely restructuring the blockchain and requiring a very serious hard fork.

But isn't VRC just a mixer?  Its still centralized and traceable.

It is a "mixing-type" of anon. It's pseudo-centralized. Centralized in the sense that it requires some sort of "master node" like system, but since we're releasing the API code to anyone, anybody can create a ring-node system. In fact we would greatly prefer that-- then we can not run our own if need be. Honestly, I would have preferred not having to run the supernodes/blockchain explorer/etc. myself... it's getting expensive and time consuming.

As for traceable, when it's deployed I'll offer a bounty to trace a single transaction. The identity of the TX Send address will unlock a zip file containing a privatekey good for some amount of VRC. I don't think it will be possible to do.

Support the VeriFund Endowment.
VRC: VFEndownxxnHea9mv59kZx8c7TysGbndYx
cryptoholic11
Hero Member
*****
Offline Offline

Activity: 490


View Profile
June 06, 2014, 05:48:09 AM
 #1807

Dumped all my CRY so I wouldnt have to cry later after being scammed. Happily bought more VRC.

exoton
Sr. Member
****
Offline Offline

Activity: 350


View Profile
June 06, 2014, 05:51:41 AM
 #1808

when is smspayment and anom life for us , im debating with myself if i should wait one week for the next paycheck to buy more or if i should borrow money to buy more , currently just holding 500 and im planning to get remotely rich of this Tongue
cyberhacker
Legendary
*
Offline Offline

Activity: 1134



View Profile WWW
June 06, 2014, 05:55:57 AM
 #1809

waiting for a richlist for VRC holders.  Roll Eyes

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
7vpo
Hero Member
*****
Offline Offline

Activity: 504

Na Zdorovie!


View Profile
June 06, 2014, 06:05:19 AM
 #1810

VeriCoin on Mintpal. Please update main thread.
kleineaap
Hero Member
*****
Offline Offline

Activity: 518


View Profile
June 06, 2014, 06:14:58 AM
 #1811

VeriCoin on Mintpal. Please update main thread.

And watch Mintpal closely btw  Wink

| Minexcoin A new era of payments

LINK TO ICO | LINK TO DISCUSSION
PUMPBANDIT
Member
**
Offline Offline

Activity: 112


View Profile
June 06, 2014, 06:18:08 AM
 #1812

VeriCoin on Mintpal. Please update main thread.

And watch Mintpal closely btw  Wink


HELL YEAH! This coin has one direction!
Dev is doing a great job, support is turning up slowly but surely!
 Cheesy
foxy
Sr. Member
****
Offline Offline

Activity: 280


CLOUT media.decentralised


View Profile
June 06, 2014, 06:23:00 AM
 #1813

wow. shots fired.

guess the next few days will separate the brains from the blaggers.

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




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


.
Media Decentralized


ICO

Twitter
Facebook
ANN Thread
Telegram
Medium
Discord


drkman
Sr. Member
****
Offline Offline

Activity: 378


View Profile
June 06, 2014, 06:52:08 AM
 #1814

The more people that hold and stake their VRC in their wallets, the higher the interest rate that EVERYONE earns so lock it up buys and girls and let's take this coin up 10x from here.
testbug
Hero Member
*****
Offline Offline

Activity: 721


poolinat0r.com - OP


View Profile
June 06, 2014, 07:01:29 AM
 #1815


There's no "truely anon" anon, just like there's no "perfect" passwords. With enough computing power you can crack anything. And that includes a decentralized system. Anyway I look forward to it. I'm happy to discuss privately if you'd like. We had a short term VRC testnet with a different merkel hash where we tested trying to send encrypted data via the message tx values but it was impossible to have efficient sends/receives. But please, before you release more details, feel free to PM me. I won't leak anything and will let you know what I think if you're interested.

SMS wallet is our top priority right now but yes we are working on our own anon features.

As a citizen of Germany, i always have to laugh when i am reading about "merkel hash" etc  Cheesy  Cheesy  Cheesy  Cheesy
CatKiwi
Full Member
***
Offline Offline

Activity: 154


View Profile
June 06, 2014, 07:29:32 AM
 #1816

The volitility of this coin today has been fantastic! Have traded my way from 2807 VRC at 10am this morning to 4620 VRC this evening. Thanks panic sellers!
stormia
Hero Member
*****
Offline Offline

Activity: 812


View Profile
June 06, 2014, 07:34:25 AM
 #1817

rofl, CRY's whitepaper is such a piece of shit.  Evidence of a total scam -- they can't even make a proper whitepaper.
...

looking through your post history it looks like you really have it out for darkcoin
shai_
Hero Member
*****
Offline Offline

Activity: 686


View Profile
June 06, 2014, 07:46:20 AM
 #1818

Im out

not gona be greedy and blow this gain

good luck fellas

look like you were right..
good that i saw your post last night
sold my VRC, which i mined with only 1 GPU... since 1 day after VRC's launch (hit some blocks!)
huge profit

Thanks for this wonderful coin and good luck to the people who bought from me

I love the idea of network dependent interest - the more the network is secure - the more everyone earns..
Lovethecoins
Hero Member
*****
Offline Offline

Activity: 658


View Profile
June 06, 2014, 07:48:09 AM
 #1819

I don't think this coin is done nearly a revamping of holders I've held my from day one and will continue to do so until the price is closer too 20k staking away for the community love this coin let's just get it going right way stop panic selling

CatKiwi
Full Member
***
Offline Offline

Activity: 154


View Profile
June 06, 2014, 08:06:17 AM
 #1820

I don't think this coin is done nearly a revamping of holders I've held my from day one and will continue to do so until the price is closer too 20k staking away for the community love this coin let's just get it going right way stop panic selling

It's just a shake out - everycoin that rises this much can and must have one. Darkcoin had it, remember Blackcoin? The shakeout at the 1500 Satoshi mark? then again at 4000 Sat, and so on. Each time however the coin pushed upwards to new highs, higher than any thought possible.

Expect VRC to shoot upwards once the so called 'weak hands' have sold. Many people mind you bought in low and will want to take their profit, cant stop em, just gotta wait for them be done.
Pages: « 1 ... 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [91] 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 ... 964 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!