Bitcoin Forum
December 11, 2016, 02:32:58 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  Print  
Author Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More  (Read 360247 times)
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
August 08, 2011, 04:57:11 PM
 #2761

Just for the record, thats bad advice Smiley.  If the current price means mining is a loss, it would be 100% stupid to continue mining.  It would be smarter to spend the money buying coins and leaving the miners off, since I'd be getting more coins for less USD.

Its not. If you want to buy you should sell your miners. But as long as you keep the miners and spect the price to go up in the future you should keep mining. Keeping the mining but not mine is the worse option. One should either sell them or mine, but not keep them idle.

Quote
I sold off a large chunk of my miners a few weeks ago because I knew that this state would be one of the first places to become unprofitable.  I sold early before the mass hardware sales began Smiley.  Now I'm just running enough to make sure the pool is still running.

That is a good decision. I didnt imagine the price of electricity in California was that bad, specially when other parts have it a lot better. Here in Europe is bad, but its more similar everywhere.
1481423578
Hero Member
*
Offline Offline

Posts: 1481423578

View Profile Personal Message (Offline)

Ignore
1481423578
Reply with quote  #2

1481423578
Report to moderator
There are several different types of Bitcoin clients. Server-assisted clients like blockchain.info rely on centralized servers to do their network verification for them. Although the server can't steal the client's bitcoins directly, it can easily execute double-spending-style attacks against the client.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 09, 2011, 04:57:43 AM
 #2762

Curious about the "Invalid" block rule.

Since it isn't actually an invalid block, rather a case of some other pool/person getting their block into the network before the pool software does - and the pool not getting the update quick enough before sending out the "late" block.
(correct me if I'm wrong about this: but I'd expect the pool to actually verify the block before posting it ... so it wouldn't actually be 'invalid' in the normal meaning of the word 'invalid' - only 'late')

So basically because of something out of the control of the miners, they get penalised by losing their shares if they don't pay 2.5% donation.
And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

If treated as normal shares, they should simply continue to count against the block that is finally won,
exactly like all other shares before the successful block already do - i.e. most shares are not from the block that wins but rather from all the blocks since the last block that won.

So ... is there a logical reason for what appears to be an illogical decision to not continue counting all shares until a block gets into the network successfully?

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
PcChip
Sr. Member
****
Offline Offline

Activity: 294



View Profile
August 09, 2011, 05:06:28 AM
 #2763

That's an interesting question.

All rates with Phoenix 1.50 / PhatK
------------------------------------------------------------------------------------------------------------------------------
5850 - 400 MH/s  |  5850 - 355 MH/s | 5830 - 310 MH/s  |  GTX570 - 115 MH/s | 5770 - 210 MH/s | 5770 - 200 MH/s
TheMalon
Member
**
Offline Offline

Activity: 70


View Profile
August 09, 2011, 06:39:44 AM
 #2764

Curious about the "Invalid" block rule.

Since it isn't actually an invalid block, rather a case of some other pool/person getting their block into the network before the pool software does - and the pool not getting the update quick enough before sending out the "late" block.
(correct me if I'm wrong about this: but I'd expect the pool to actually verify the block before posting it ... so it wouldn't actually be 'invalid' in the normal meaning of the word 'invalid' - only 'late')

So basically because of something out of the control of the miners, they get penalised by losing their shares if they don't pay 2.5% donation.
And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

If treated as normal shares, they should simply continue to count against the block that is finally won,
exactly like all other shares before the successful block already do - i.e. most shares are not from the block that wins but rather from all the blocks since the last block that won.

So ... is there a logical reason for what appears to be an illogical decision to not continue counting all shares until a block gets into the network successfully?
You are wright, it "appears to be an illogical decision" ... but is not. Its just a decision based on how bitcoin works.
At present technological level of our society, every information (digital or not) takes time to reach its destination. Its perfectly normal that a block to be "discovered" by two different miners almost at the same time, lets say 10ms one of each other (at 100Mhs in 10ms are calculated 1.000.000 hashes) . The blocks are perfectly valid for the two miners and they publish it. Now the bitcoin clients present in the network start to validate this 2 blocks. At this point is only the luck that matters because the winner block will be the block that gets faster validations (it can be the second published block that wins if "near" him are more bitcoin clients present that validate it).
So, luck being intrinsic to the validation of block a decision must be taken, and every pool made a decision.
Keep in mind that if you were a solo miner you have been lost all the work ... in fact some pools don't pay for invalid blocks.
And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.
You are misled ... they are not payed from the work of other miner done in another block ... "pool's funds" means btc donated ... (mostly from the ones who donate 2.5%) so it seems a correct decision to give to them something back when we get unlucky.
Ciao.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 09, 2011, 07:49:26 AM
 #2765

Curious about the "Invalid" block rule.

Since it isn't actually an invalid block, rather a case of some other pool/person getting their block into the network before the pool software does - and the pool not getting the update quick enough before sending out the "late" block.
(correct me if I'm wrong about this: but I'd expect the pool to actually verify the block before posting it ... so it wouldn't actually be 'invalid' in the normal meaning of the word 'invalid' - only 'late')

So basically because of something out of the control of the miners, they get penalised by losing their shares if they don't pay 2.5% donation.
And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

If treated as normal shares, they should simply continue to count against the block that is finally won,
exactly like all other shares before the successful block already do - i.e. most shares are not from the block that wins but rather from all the blocks since the last block that won.

So ... is there a logical reason for what appears to be an illogical decision to not continue counting all shares until a block gets into the network successfully?
You are wright, it "appears to be an illogical decision" ... but is not. Its just a decision based on how bitcoin works.
At present technological level of our society, every information (digital or not) takes time to reach its destination. Its perfectly normal that a block to be "discovered" by two different miners almost at the same time, lets say 10ms one of each other (at 100Mhs in 10ms are calculated 1.000.000 hashes) . The blocks are perfectly valid for the two miners and they publish it. Now the bitcoin clients present in the network start to validate this 2 blocks. At this point is only the luck that matters because the winner block will be the block that gets faster validations (it can be the second published block that wins if "near" him are more bitcoin clients present that validate it).
So, luck being intrinsic to the validation of block a decision must be taken, and every pool made a decision.
Keep in mind that if you were a solo miner you have been lost all the work ... in fact some pools don't pay for invalid blocks.
Hmm - you haven't actually answered the question in reality.
You've just repeated what I asked as an answer if you look at the details of what you have said.
Since: yes I realise that already, that was the point of my question Smiley

The comparison to a solo miner is actually not relevant.
A solo miner gets all the BTC of their effort when they succeed in getting a block 'first' on the network.
If they put a block answer on the network too slowly, this does not effect the % of the BTC they receive next time they succeed in being 'first'

A pool determines to divide up the BTC usually based on the % of the total effort.
The fact that one person submits a possible solution to a block should not invalidate all the work that went before.
There is certainly no logical stand for that - since when a solution is submitted and wins - most of the work that counts for shares has nothing to do with the block that has been won - most of the shares are no different at all to the shares of an invalid block that has occurred directly before the successful block.

And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.
You are misled ... they are not payed from the work of other miner done in another block ... "pool's funds" means btc donated ... (mostly from the ones who donate 2.5%) so it seems a correct decision to give to them something back when we get unlucky.
Ciao.
No I didn't mean is was bad for the miner, I meant it was bad for the pool's funds.
I'm not trying to lead people astray Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
August 09, 2011, 09:15:51 AM
 #2766

I can see it both ways.

From a miner's perspective, in a proportional pool, if he submits a share, he expects to get some (however fractional) payout in theory. If his share was submitted during an invalid block he won't though, through no fault of his own.

From the pools perspective, as soon as bitcoind says 'gratz you got a block' the pool closes the current round, and starts a new one. Only afterwards when bitcoind decide to change it's mind and take back it's initial claim does the pool declare a block invalid.

From a programmatic standpoint it is much easier to count invalid rounds as their own round, since you won't need special logic for it. Just to take the shares away when bitcoind changes its mind.

Looking at it logically, I can see your point though. But still, I don't think it's worth it. In essence, the miner got shares in a block. They were just later taken away. Rolling these shares back into the current round would probably be too much of a hassle. And then, what would you do with the 2.5% people? Count their shares twice???

And we are talking about BTC Guild, the 2nd biggest pool. It isn't like you might waste a week of hashing for an invalid block in a small pool. Maybe a few hours at worst.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 09, 2011, 12:32:33 PM
 #2767

Hmm I guess the real answer is probably that those who decided didn't really understand what an 'invalid block' was at the time and the decision has stuck Tongue

As for programming, it's simple if the actual shares are logged.
I'd expect they are - even pushpool does it (with the block number the share was generated for)
I would be surprised if any system would risk only keeping a numerical count of the shares - since a single record corruption could represent a loss of the total share record of a user for a round and be unrecoverable.

Thus when determining the round it would logically be the count of shares from the block number after the last successful up to the new successful block number
(instead of from the block number after the last successful or the last invalid up to new the successful block number)
Logically the same and most likely just as simple.

Also there would be no need to specially handle the 'invalid block' - possibly just remove it.
Since payout is well after the new block is found - the correction of the found block records (removal of the invalid) would be simple and all that is needed to correct the share calculation (i.e. the invalid block doesn't exist any more - which is shouldn't anyway)
... long ramble - but just pointing out that there is no odd complexity involved ... and a simplicity as well.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
August 09, 2011, 12:39:52 PM
 #2768

Upon further reflection, you are probably right. The correct thing to do would be to put all of the invalid round's shares into the new round.

The thing that convinced me of this is the case where a small pool gets an invalid. It would be wrong in that case to throw away a weeks worth of work because of that. And if it is wrong in that case, it is wrong in all cases.

2.5% contributors would be double paid for shares, but the pool wouldn't lose any money from this at all.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 09, 2011, 01:17:15 PM
 #2769

Hmm I guess the real answer is probably that those who decided didn't really understand what an 'invalid block' was at the time and the decision has stuck Tongue

Seriously?  Your theory is that the guy that created and operates the second largest pool is an idiot?

There is absolutely no mathematical difference between the two choices, in the long run.  This should be self evident, but if you don't believe me, you can check this yourself by looking at the round history and calculating what your payout would have been if each invalid round had been merged with the round after it.  Be sure to look at all of the invalid blocks though, because while you might be up or down a couple of percent on any given round, they will (must!) average out to zero in the long run.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
August 09, 2011, 01:26:20 PM
 #2770

Hmm I guess the real answer is probably that those who decided didn't really understand what an 'invalid block' was at the time and the decision has stuck Tongue

Seriously?  Your theory is that the guy that created and operates the second largest pool is an idiot?

There is absolutely no mathematical difference between the two choices, in the long run.  This should be self evident, but if you don't believe me, you can check this yourself by looking at the round history and calculating what your payout would have been if each invalid round had been merged with the round after it.  Be sure to look at all of the invalid blocks though, because while you might be up or down a couple of percent on any given round, they will (must!) average out to zero in the long run.

The difference is on what a share is. Is it the right to get a payout proportional to the number of shares that were submitted since the last valid block? Or is it the right to get a payout proportional to the number of shares that were submitted since the last block as long as the network deems the next block that the pool thinks it finds is valid.

Mathematically you are correct, assuming no pool hopping, constant hash rates, etc etc.
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
August 09, 2011, 01:56:04 PM
 #2771

Banned a brand new botnet that decided to give our pool a test that was hogging resources for long poll connections on US Central.  Also banned a user who was operating between 15 and 20 GH/s but running at 2-3% efficiency.  I'm not fond of somebody requesting 5+ million getworks in a 24 hour period but only sending in ~100k shares, which means he was putting nearly 1 TH/sec worth of load on bitcoind.


Regarding invalid rounds:  Most pools roll them into a new round because they don't offer ANY payment on them.  We do for quite a few users (average payouts on invalid rounds at ~15 BTC).  In a proportional pool, whether the shares are rolled forward has negligible impact on the end reward.  If people were leaving during the invalid round/next round, you get MORE due to the share reset.  If people were joining during the invalid round/next round, get get less due to the share reset.  We're talking about a very short time frame [a few hours if we're unlucky, a few minutes if we're lucky], where the pool speed is not likely to fluctuate much in either direction during that short time span.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
August 09, 2011, 03:33:17 PM
 #2772

"1.5% (Not yet implemented) - Automatic payouts.  User is allowed to pick either a daily time to receive payout, or a specific amount."

Looking forward to seeing this added, what time frame can I expect before this feature is working?


Bringing this back up...

It's being worked on.  The current testing code takes far too long to run, and I'm worried that the long run time could cause a double payout if somebody tried to get a payout during the script.  I'm working on optimizing how user rewards are stored/accessed so it runs almost instantaneously, that way I can simply lock payouts while the script runs and turn it back on when it exits without inconveniencing too many people.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Nicksasa
Sr. Member
****
Offline Offline

Activity: 288



View Profile WWW
August 09, 2011, 06:10:32 PM
 #2773

Banned a brand new botnet that decided to give our pool a test that was hogging resources for long poll connections on US Central.  Also banned a user who was operating between 15 and 20 GH/s but running at 2-3% efficiency.  I'm not fond of somebody requesting 5+ million getworks in a 24 hour period but only sending in ~100k shares, which means he was putting nearly 1 TH/sec worth of load on bitcoind.


Regarding invalid rounds:  Most pools roll them into a new round because they don't offer ANY payment on them.  We do for quite a few users (average payouts on invalid rounds at ~15 BTC).  In a proportional pool, whether the shares are rolled forward has negligible impact on the end reward.  If people were leaving during the invalid round/next round, you get MORE due to the share reset.  If people were joining during the invalid round/next round, get get less due to the share reset.  We're talking about a very short time frame [a few hours if we're unlucky, a few minutes if we're lucky], where the pool speed is not likely to fluctuate much in either direction during that short time span.
I keep wondering why botnet owners are too lazy to setup their own pool, you know you'll get banned eventually.

sirky
Sr. Member
****
Offline Offline

Activity: 407



View Profile
August 09, 2011, 06:19:55 PM
 #2774

Banned a brand new botnet that decided to give our pool a test that was hogging resources for long poll connections on US Central.  Also banned a user who was operating between 15 and 20 GH/s but running at 2-3% efficiency.  I'm not fond of somebody requesting 5+ million getworks in a 24 hour period but only sending in ~100k shares, which means he was putting nearly 1 TH/sec worth of load on bitcoind.


Regarding invalid rounds:  Most pools roll them into a new round because they don't offer ANY payment on them.  We do for quite a few users (average payouts on invalid rounds at ~15 BTC).  In a proportional pool, whether the shares are rolled forward has negligible impact on the end reward.  If people were leaving during the invalid round/next round, you get MORE due to the share reset.  If people were joining during the invalid round/next round, get get less due to the share reset.  We're talking about a very short time frame [a few hours if we're unlucky, a few minutes if we're lucky], where the pool speed is not likely to fluctuate much in either direction during that short time span.
I keep wondering why botnet owners are too lazy to setup their own pool, you know you'll get banned eventually.

Because it is hard to support that many connections!
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 09, 2011, 07:23:04 PM
 #2775

Hmm I guess the real answer is probably that those who decided didn't really understand what an 'invalid block' was at the time and the decision has stuck Tongue

Seriously?  Your theory is that the guy that created and operates the second largest pool is an idiot?

There is absolutely no mathematical difference between the two choices, in the long run.  This should be self evident, but if you don't believe me, you can check this yourself by looking at the round history and calculating what your payout would have been if each invalid round had been merged with the round after it.  Be sure to look at all of the invalid blocks though, because while you might be up or down a couple of percent on any given round, they will (must!) average out to zero in the long run.
Seriously, my theory is that whoever made that rule did not understand what an 'invalid block' is.
Because it is 'nothing' - it should not effect the payout - but it does.
Thus clearly misunderstood by whoever decided it should effect the payouts.

It has no effect on the amount of BTC received by the guild.
It has no effect on the share load on the guild.
Mathematically, it SHOULD have no effect on the payout of the guild.

It reduces the payouts for some.
Increases the payouts for others.
AND increases the payouts for the guild.

An example where it has made a difference: block 235891
Some people who worked on that who didn't have 2.5% donation got nothing.
Cause: the previous 'round' was an 'invalid block' and this 'round' was only 7 seconds.
No averaging will correct the lost amounts.

Yes there is a mathematical difference (though that was obvious from the start)

Edit: though I should add that your argument is in agreement with my suggestion that the pool should ignore them: " ... ... ... zero in the long run"

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
cyberlync
Full Member
***
Offline Offline

Activity: 226



View Profile
August 09, 2011, 11:41:26 PM
 #2776

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

Giving away your BTC's? Send 'em here: 1F7XgercyaXeDHiuq31YzrVK5YAhbDkJhf
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
August 09, 2011, 11:56:13 PM
 #2777

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

How long ago was it?

Estimated rewards applies to the current round.  Unconfirmed rewards applies to rounds in the previous 120 blocks.  24 Hour Rewards applies to the previous 24 hours.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
cyberlync
Full Member
***
Offline Offline

Activity: 226



View Profile
August 09, 2011, 11:58:24 PM
 #2778

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

How long ago was it?

Estimated rewards applies to the current round.  Unconfirmed rewards applies to rounds in the previous 120 blocks.  24 Hour Rewards applies to the previous 24 hours.

Umm, it was around the time I wrote the message, not more than half an hour prior to that. So there should be something in Unconfirmed and 24 Hour rewards.

Giving away your BTC's? Send 'em here: 1F7XgercyaXeDHiuq31YzrVK5YAhbDkJhf
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
August 10, 2011, 12:04:01 AM
 #2779

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

Estimated Rewards are calculated by your current mining speed (15 minute average) vs total pool speed, rather than shares in the round vs total, to stop pool hopping.

The round you were mining in is still going if it was that recent, so your estimated has dropped to 0 since your speed is currently 0.  Since the round hasn't ended [or it hasn't been announced due to the 1 hour delay], your unconfirmed hasn't gone up yet.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
cyberlync
Full Member
***
Offline Offline

Activity: 226



View Profile
August 10, 2011, 12:06:28 AM
 #2780

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

Estimated Rewards are calculated by your current mining speed (15 minute average) vs total pool speed, rather than shares in the round vs total, to stop pool hopping.

The round you were mining in is still going if it was that recent, so your estimated has dropped to 0 since your speed is currently 0.  Since the round hasn't ended [or it hasn't been announced due to the 1 hour delay], your unconfirmed hasn't gone up yet.

Makes perfect sense. Thank you for the fast reply!!!

Giving away your BTC's? Send 'em here: 1F7XgercyaXeDHiuq31YzrVK5YAhbDkJhf
Pages: « 1 ... 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 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 »
  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!