Bitcoin Forum
December 08, 2016, 04:15:12 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 [1208] 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1805877 times)
Rizla2345
Full Member
***
Offline Offline

Activity: 238


View Profile
May 16, 2015, 01:05:38 AM
 #24141

The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?
1481170512
Hero Member
*
Offline Offline

Posts: 1481170512

View Profile Personal Message (Offline)

Ignore
1481170512
Reply with quote  #2

1481170512
Report to moderator
1481170512
Hero Member
*
Offline Offline

Posts: 1481170512

View Profile Personal Message (Offline)

Ignore
1481170512
Reply with quote  #2

1481170512
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
sidhujag
Legendary
*
Online Online

Activity: 1288


View Profile
May 16, 2015, 03:08:23 AM
 #24142

The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?
I like the stock market here.. Lots of high risk gamblers will make a fortune in coming time.. Usd also a good buy right now.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 16, 2015, 04:00:12 AM
 #24143

Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.

This is an idea which I have been mulling over since Gavin came up with IBLT, but have not expounded because, until recently I did not realise the depth of support within Core dev for maintaining the 1MB. If dev are not able to compromise on a can-kick, e.g. 20MB, or an adaptive limit which leverages the demand for larger blocks with pressure to keep a cleaner UTXO set / better fees market, then there is an alternative. Also, Pieter's "headers-first" change which went live in version 0.10 makes this alternative safer on resync.

A "third way": Decoupling the size limit check on blocks from new block messages.

Today, the 1MB size limit is bluntly used to check any block which a node sees. It does not matter whether the block being checked is 2 years old and just read from disk, or whether it is a new block announcement to a fully-synced node. The principle here is that the 1MB check would be retained for new block announcement messages, but not when processing old blocks, or applied after a new block is constructed from an announcement message.

A hard-fork is still required, as the window is then opened for blocks to be accepted which are >1MB on disk, and to support compression/decompression of new blocks.  All nodes will need to be able to decode blocks which might be compressed by different methods.

Notes:

Bandwidth usage for new blocks is kept to 1MB per 10 minutes. People can continue to mine via TOR.

More than one type of compression would then be supported, e.g. IBLT and transaction hash lists, so miners have a choice of which to use. IBLT could be used on top of hash lists which gives even greater compression. CPU overhead is a consideration.

The network can already handle a much higher tps of real-time unconfirmed tx so block propagation methods which rely on the initial publication of tx are encouraged.
e.g. IBLT usage is incentivized for miners wanting to construct blocks larger than 1MB. This also reduces blockchain spam as miners cannot stuff new blocks >1MB with secret transactions. This reduces the rate of increase in UTXO relative to average block size increase.

Fees on a 20MB disk block would approximate the 6.25 reward in 5 years time. This happy state could be reached while retaining the 1MB limit on new block messages.

Resync would still require sending blocks >1MB, however this is not on the critical path for the whole network, just one node.

Current status:

Wladimir has indicated that he wants to close off version 0.11 soon.
If nothing is done about the 1MB in version 0.11 then one of the last chances is wasted for achieving a smooth transition to larger tx volumes without a period of serious confirmation delays, (user unhappiness, bad publicity, price hit, harm to the network effect).

I suggest that if no compromise is possible in dev on the 1MB then at the very least version 0.11 should prepare the way for block compression, and provide an incentive for it to be used, incorporating software to decode an IBLT, and be able to use transaction hashes like the block relay service. This might take a number of weeks/months, but far less time than waiting for Lightning Networks, tree-chains, or other off-chain scaling solutions.

IMHO, the safest hard fork uses both a block version transition PLUS a 30 or 60 day grace period. i.e. after the 75% target is reached, a delay occurs before the change becomes effective. This achieves mining consensus and also allows non-mining nodes and laggard miners more time to upgrade.

Have at it!

Rizla2345
Full Member
***
Offline Offline

Activity: 238


View Profile
May 16, 2015, 04:13:48 AM
 #24144

The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?
I like the stock market here.. Lots of high risk gamblers will make a fortune in coming time.. Usd also a good buy right now.

Well, you know what they say, sell when they yell etc. It looks rather stretched to me, that is DOW, NAS, S&P. But I suspect that there might be something attractive in smaller caps which have been overlooked while the big boys were being pumped up.
sidhujag
Legendary
*
Online Online

Activity: 1288


View Profile
May 16, 2015, 04:18:15 AM
 #24145

The stock market seems ripe for a major collapse. Is gold likely to rocket? And bitcoin? Also the dollar has been sagging quite a bit lately. That should help gold but what about BTC?
I like the stock market here.. Lots of high risk gamblers will make a fortune in coming time.. Usd also a good buy right now.

Well, you know what they say, sell when they yell etc. It looks rather stretched to me, that is DOW, NAS, S&P. But I suspect that there might be something attractive in smaller caps which have been overlooked while the big boys were being pumped up.
It will rise until average joes are talking about how great the market is again.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 16, 2015, 04:58:03 AM
 #24146

as Bitcoin has alot of enemies, why do you think we aren't seeing a regular stream of these types of blocks?

I'm not trying to be conspiratorial here, just factual, but there is no real gain in doing it at 1 MB. 1 MB was chosen to be a size that is fairly immune to spamming attacks. Opinions differ I guess about whether 20 MB is similarly immune.

Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was to change bitcoind nodes to only consider certain types of transactions as "standard" and not re-transmit transactions that did not qualify as "standard", these have since been called "non-standard". Along with this change many miners decided to not include these "non-standard" transactions either (but some still do).

This did not require a fork because the base protocol, which is defined by what constitutes a valid block, did not change.

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

So how come they appear in the unconfirmed transaction list on blockchain.info?


Because someone sent them to blockchain.info directly, or they were relayed by a node that ignores the "non-standard" agreement (not rule). blockchain.info's website is also setup to be a view of the network, they include visibility into strange and other transactions. So it would make sense they would also display information on non-standard transactions that most node's won't re-transmit.

Again they are valid transactions, it's just an informal agreement to ignore/limit them. A formal agreement requires a hard fork.

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from  changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.

Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.

Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.

Take LukeJr's insertion of Ubuntu nodes that block SatoshiDice type services into the Ubuntu default client. This was not a fork because he simply made the nodes decide not to relay transactions to/from specific addresses, but these nodes still followed the same rules on what is a valid block, and so they would accept these transactions after they were confirmed in a block. (To do otherwise would be a fork and they would be kicked onto their own tiny chain).

and your definition of a hard vs soft fork?

They are both forks in the sense above.

The difference is in whether or not all nodes need to change to accept blocks under the new rules or if the change is backward compatible and old nodes can still function without changing themselves.

This is a good description
http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork

Obviously a soft fork is easier to roll out. A hard fork required everyone to agree to the change and the exact block to change.
PenguinFire
Full Member
***
Offline Offline

Activity: 154


That Darn Cat


View Profile
May 16, 2015, 04:59:26 AM
 #24147

Based on the responses, gold and Bitcoin are not very related at all.  Is  that the summery here?

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 05:42:59 AM
 #24148

Your whole attitude of riding into this thread on your high horse and 'prodding' people who I have come to hugely respect is pushing it, though.

I respect many of those in this thread who deserve the respect because their comments are factual (or they don't persist ignorantly when someone points out an error) and they don't pick silly fights with me because of ego. Examples include Peter R, NewLiberty, smooth, etc.. Note what I did not write. Did I write they want to associate with me?

You're being a know-it-all and smartass and you should be clever enough to predict the reaction and you should be emotionally prepared for it.

Yes I know the reaction of b-listers when they are factually corrected. Instead of recognizing error and moving forward on learning and synergy, they play their egos all over the thread wasting all our time.

My mistake is letting them drag me into it, thus making it appear as I am the one with the problem.

It seems you aren't and frankly name-calling is something I hadn't expected from you. Kinda sad.

If you interpret a little tease as disrespect then that's entirely on you.

If you interpret "arsehole" as disrespect then that's entirely on you.  Huh

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 05:48:47 AM
 #24149

IMO this block size debate is not about block size but other interests.

Correct (I agree). The block size must be increased. Within the current design (even with IBLT) this is driving Bitcoin towards centralization as I have outlined. And only a radical redesign that removed transaction data from blocks could change that. So increasing block size and implementing IBLT has to be done and moving towards censorship (via increased centralization) has to be accepted. The only alternative is radical redesign.

Butthurt idols aside, it is better when we deal in reality and not fantasy. I would bother to explain why mentioning Nash equilibrium in this context is not applicable, but I see that my efforts here are not welcome.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 05:57:42 AM
 #24150

it seems to me that the Nasdaq is not only going to want it but demand it if they want to transact shares off the blockchain.  seems to me that Goldman Sachs is not only going to want it but demand that Circle be able to act as a MSB so they can get a return.  seems to me that the NYSE is not only going to want it but demand that Coinbase be able to act as a MSB so they can get a return.  i also think that guys like Arthur Levitt, Vikram Pandit, Eric Schmidt, Reid Hoffman, Li Ka Shing, Richard Branson, the Winklevii, Andresen, Sheila Bair, Blythe Masters are NOT going to take kindly to their millions of investment capital being vaporized by some politicians.

i also highly doubt that the Chinese Mandarins are going to cooperate with the USG apparatchiks to prop up a sinking USD.  not to mention Iran & Russia.

I don't know what part of "centralization" you thought you were refuting.  Huh You appear to be describing centralization underway.

I don't know why you think the global elite wouldn't profit from destroying the USD as they usher in a political multi-polar world run top-down with a one-world reserve currency. China and Russia are in the power sharing agreement of the elite and the plans to enslave the minions and maximize fascist profit with a Global Technocracy.

I don't have more time to expend on you. Sorry.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 06:04:31 AM
 #24151

Your self-proclaimed superior intelligence is going to waste

I don't claim to have superior intelligence over every member of this thread and certainly not in every facet of knowledge (that would be absurd). I know for a fact that both smooth and Peter R have corrected me in the past. I get frustrated that I can't write something critical, succinct, and factual without inflaming someone's ego.

I make some succinct corrections and insights and this appears to set off the egos of those b-listers who are being debated. Note however, the way the discussion between NewLiberty and myself proceeded in this thread. There was no inflamed ego, so you probably missed the factual discussion. Try to review and see how I cordially I debate with those who are interested in useful discussion and not ego wars.


Doesn't make sense that the protocol allows non standard TX's to be accepted in block form by nodes yet at the same time they won't relay or accept them if simply propagated.

The transactions were always valid.

To make them invalid would require a hard fork. We try to avoid hard forks for obvious solutions.

So the compromise was...

As a consequence, non-standard transactions can still be included in a block because they are valid transactions from a block verification standpoint. However to discourage them, most P2P nodes and most miners ignore them.

You added to my knowledge. Normally I don't acknowledge, because it is noisy to do so. Just this once, so that others will understand I don't think I have all the knowledge (would be an absurd claim).

Cconvert2G36
Sr. Member
****
Offline Offline

Activity: 392


View Profile
May 16, 2015, 06:06:47 AM
 #24152

I don't have more time to expend on you. Sorry.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 06:07:49 AM
 #24153

I don't have more time to expend on you. Sorry.



haha. b-listers are so clueless.

No I have work to do.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 06:11:52 AM
 #24154

The boxing video inputs pushed the topic of Bitcoin out of my entertainment zone.

So why did you watch them? (don't try to pretend you didn't otherwise you wouldn't know their content with confidence)

If you see I am in a silly wrestling match with Cypherdoc then why are you bothering to click youtubes in a post where he and I are not discussing anything factual.

TPTB (no pun intended) would be a little more effective if he understood the value of attention.

Here we have a supposedly serious technical thread started by a b-lister in a Speculation forum and you expect to have noiseless and efficient A-lister geek discussion  Huh

The mistake is who is allowed to post here. I shouldn't be posting here because of who else is allowed to post here. That is if you want to have a very high S/N.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 06:25:39 AM
 #24155

we know that full nodes have unconf tx sets that correspond by somewhere over 90%; which is why IBLT could work to communicate across the network that a new block has been solved.  the ppl who argue against raising the 1MB cap say that an attacker could create these bloated blocks to torment small miners.  the question is, where would they get the extra tx's to construct this bloat?

I don't know about the arguments of others, but my argument is that at some level of scale the small miners can't keep up with all those transactions. My point was never against raising the blocksize of Bitcoin. My point is that Bitcoin as it is currently designed where every full node must see and verify every transaction, can't scale without being centralized (or moving transactions offchain which is the same thing as centralization if they will be done offchain on the servers of the behemoths if the fundamental blockchain scaling issue has remained unresolved).

I thought that was an obvious implication from my posts. If I write everything that is obviously implied then my posts become verbose walls-of-text. If I don't write what should be deducible, then some allege that I don't make sense or write vaguely. I can't win either way.


On the UTXO topic, the distribution of balances here

http://bitcoinrichlist.com/charts/bitcoin-distribution-by-address?atblock=350000

shows that 96.97% of addresses contain less than 0.001 BTC. Now these are address totals, any analysis of UTXO outputs would show that more than 96.97% of UTXO outputs contain less than 0.001BTC.

I think this shows that the UTXO is already vastly populated by dust nonsense that simply sits around. If UTXO size becomes an issue any intelligent implementation could easily swap these out to a lower tier of storage. Most of this dust will never be spent simply because you'd have to pay more in fees than the output is worth, spending them is literally burning money.

1. You are not addressing the fundamental scaling issue, rather doing some bounded compression.

2. As BTC rises in price, dust may become spendable.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 06:55:24 AM
 #24156

So any code changes made to the Bitcoin Core client do not require forks which is to be distinguished from  changes to the protocol which defines what is acceptable as a block and requires a fork?

I'd define it as Bitcoin is the blockchain data structure and the set of rules that govern what constitutes a valid block. If you want to change the rules that govern what is a valid block (transactions and block structure) then that is a fork. Anything else is not a fork. The reasoning is simple, these are the rules that govern if a specific chain is valid and thus govern consensus.

Nodes however can operate however they want, as long as they agree on the rules that define a valid block. If some nodes decide on a different set of rules, then they will be forced onto their own chain and lose consensus with the main chain.

Take Gavin's IBLT proposal as an example. This is a major change to bitcoind that changes how nodes communicate blocks to each other. This is not a fork simply because it does not change anything at all about what defines a valid or invalid block. Just the communication of blocks.

If all full nodes don't adopt the change then IBLT doesn't function (or the nodes that don't adopt it, are in a major disadvantage in terms of orphan rate and earnings and thus they fall away), thus it is a hard (i.e. non-optional feature change) fork.

Peter R asked me upthread to explain why I think it is a hard fork. So there is my explanation.

TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 08:57:52 AM
 #24157

Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.

If I understand correctly what you have proposed, then essentially you are allowing miners to create chains with larger blocks (e.g. by having with sufficient hashrate either IBLT coordination or sufficient bandwidth connectivity) but miners should not be penalized (i.e. not censored from the relay network) for not propagating a new block announcement that is greater than 1MB.

Thus afaik this proposal only gets around the objections of core devs if it is really just a rollout plan for IBLT. Otherwise these larger blocks are penalizing (with higher orphan rate and/or late announcement) those smaller miners with lesser connectivity.

There are only two ways forward that don't lead to technical problems with transaction processing or smaller miners:

1. Rollout IBLT. (long-term solution and I assert centralizes Bitcoin which is why I characterized it as "won't work" meaning won't maintain the fundamental tenet[1]).

2. Increase txn fees to curtail rate-of-expansion of the txn rate.  (short-term, kick-the-can)

Are there core devs protesting against IBLT?

P.S. If IBLT can't be rolled out fast enough, then #2 is the only option I see. The hard fork of increasing the blocksize to 20MB is likely not politically possible as a kick-the-can (and perhaps not advisable also).

[1]https://bitcointalk.org/index.php?topic=68655.msg11331322#msg11331322
https://bitcointalk.org/index.php?topic=68655.msg11334337#msg11334337
https://bitcointalk.org/index.php?topic=68655.msg11331549#msg11331549

Odalv
Legendary
*
Offline Offline

Activity: 1064



View Profile
May 16, 2015, 09:39:56 AM
 #24158

Compromise solution: up to 500 tps on-chain while keeping the 1MB limit, however, a hard-fork is still needed.


I do not understand how you can add 300,000 transaction * 250 bytes into 1 MB block.   500 tps is 75 MB every 10 minutes. (or will you have 75 * 1 MB blocks every 10 mins ? )
tabnloz
Hero Member
*****
Offline Offline

Activity: 793


View Profile
May 16, 2015, 10:31:22 AM
 #24159

it seems to me that the Nasdaq is not only going to want it but demand it if they want to transact shares off the blockchain.  seems to me that Goldman Sachs is not only going to want it but demand that Circle be able to act as a MSB so they can get a return.  seems to me that the NYSE is not only going to want it but demand that Coinbase be able to act as a MSB so they can get a return.  i also think that guys like Arthur Levitt, Vikram Pandit, Eric Schmidt, Reid Hoffman, Li Ka Shing, Richard Branson, the Winklevii, Andresen, Sheila Bair, Blythe Masters are NOT going to take kindly to their millions of investment capital being vaporized by some politicians.

i also highly doubt that the Chinese Mandarins are going to cooperate with the USG apparatchiks to prop up a sinking USD.  not to mention Iran & Russia.


I don't know why you think the global elite wouldn't profit from destroying the USD as they usher in a political multi-polar world run top-down with a one-world reserve currency. China and Russia are in the power sharing agreement of the elite and the plans to enslave the minions and maximize fascist profit with a Global Technocracy.

I don't have more time to expend on you. Sorry.

This may be a very simple reading of it, but wouldn't a one world currency run into the same problems the Euro has, just on a larger scale? (ie, smaller less competitive nations are disadvantaged and have very little wiggle room in case of downturn etc)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
May 16, 2015, 10:43:38 AM
 #24160

NYT has an article claiming Nick is Satoshi.

http://www.nytimes.com/2015/05/17/business/decoding-the-enigma-of-satoshi-nakamoto-and-the-birth-of-bitcoin.html?_r=0

While I agree the evidence shows him to be in the likely list, there is a pool of other people who worked on similar projects and participated in similar forums, any one of which could be Satoshi as well.

Nick Szabo understood the critical importance of the fundamental tenet of not needing "trusted third parties" (a.k.a. TTP), i.e. the bearer nature of personal property.



I don't think Nick Szabo would have designed Bitcoin because he understood very well that you can't trust hash function to be fair. I don't think he had reasoned out how to avoid the inevitable centralization he was trying to avoid.

One plausible scenario is the DEEP STATE found Nick's work (because they are following closely influential gold bugs, Libertarians, and Bit Gold created a mini uproar even I was sent a link to it before Bitcoin became known) and realized he had identified how to create a system that would give them exactly what they wanted. It is plausible that Nick being the very smart guy he is, knows what has happened and this could be another reason that he has apparently been keeping a very low profile.

Another possibility is Nick clearly understood the profit potential as he mentioned in the Bit Gold essay. So he may have created Bitcoin knowing full well that he was handing a monster against humanity to those with the power to invest $billions in custom hardware. He may have done this thinking it might drive the economic incentives and avenues for spawning a better solution. In this case, the correlation of his May 2011 disappearance to Satoshi's brings to my mind that Satoshi wanted to disappear when he heard about some major press that Bitcoin had just received.

It is very odd that not one photo and no life history can be found of him online. And that he was allegedly present at some Goldman Sachs employee's Lake Tahoe condo where a NYT journalist is.

S(atoshi) N(akamoto)
N(ick) S(zabo)

Whoever created Bitcoin is at least wanting to point to him.

Pages: « 1 ... 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 [1208] 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 ... 1560 »
  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!