One could adjust the difficulty every block without any complex mathematics or issues with synchronizing times. Now mining is random we only know the time of the average block which is 10 minutes however each individual blocks time to a solution will fall into a bell curved (visualize a bell curve with peak at 10 minutes and a standard deviation of 10 minutes).   If you simply looked at the last block the difficulty adjustment would just be tracking the normal random walk of bitcoin solution times.  Bitcoin "solves" that by looking at a 2016 block window and adjusting it every 2016 blocks.  However it isn't required that the adjustment interval and the averaging interval be the same.

For example a CC could look at time for last 2016 blocks to get the average time per block (and thus the necessary change in difficulty) but do that every block.

For example:
for block 2017 the difficulty is computed by looking at the time interval from block 1 to block 2016
for block 2018 the difficulty is computed by looking at the time interval from block 2 to block 2017
for block 2019 the difficulty is computed by looking at the time interval from block 2 to block 2018
...

In related news you can buy $200 million dollars for just $1 dollar. 

Utterly incapable of doing anything else at any speed.

"Bitcoin" ASICS aren't "Bitcoin" ASICS, they aren't even "general purpose SHA-256 hashing" ASICs, they are "given a 76 byte  header, and a target, append a 4 byte nonce beginning with 0x00000000 to the end of the header, hash the resulting binary value with the SHA-256 algorithm, then hash the output with a second SHA-256 hash, check the resulting double hash against the provided target, if smaller than target save the nonce for return, if not discard, then keep incrementing the nonce performing the same process on all nonces until the max nonce (0xFFFFFFFF) is reached, then restart with a new header and target" ASICs.  We just say Bitcoin ASIC because that is kinda long but they are that specific.

For anything other than that EXACT problem they are utterly worthless.

This.  Sadly password reuse is a problem and sites shouldn't pretend it isn't.  Also humans generally have a problem coming up with high entropy passwords.  If someone used a particular password even once the odds are someone else on the planet also used it.  Without salt precomputation against known/compromised passwords becomes trivially easy.  

At a minimum:
a) modern cryptographically secure hashing algorithm with no known preimage attacks (second generation RIPEMD, SHA-2, SHA-3, bcrypt*, Scrypt, Whirlpool, etc)*.  
b) 64 bit or greater salt.**
c) hash length of at least 128 bits
d) enforce minimum 8 digit password length ***

An even stronger solution is:
a) use a key derivative function designs to slow down brute force attacks (key stretching). Examples include bcrypt, scrypt, and PBKDF2 ****
b) enforce minimum password length 8 digits is acceptable for higher security applications adding even a single digit (9 digits) can provide significant security ***
c) check users password against lists of known compromised passwords and reject.

For example using bcrypt, requiring a min of 9 characters and ensuring the password isn't on any compromised password dictionary list makes the probability of brute forcing the password negligible even using botnets, cloud computing, or dedicated (non-existent) ASICs.  It is also likely to remain negigible even considering the advancements in computing power over the next couple decades.  For a more exotic solution which provides the site plausible deniability and puts all the security requirements on the user one could use public key signing (Bitcoin address or PGP) as a method of authenticating (logging on) users.

For those who want an appeal to authority this is what NIST recommends as a minimum:  
a) Key Derivative Function: PBKDF2 key using SHA-2 (SHA-3 maybe? but not at the time of this doc)
b) Min salt length: 128 bits
c) Min digest (hash) size: 112 bit
d) Min number of iterations: 1,000 for time sensitive applications (for high security situations that are not time sensitive a much higher iteration count based on available computing power should be used potentially up to 1,000,000 iterations)
e) Min password length: 10 digits for passwords which should consist of mixed symbols, numbers, upper case, lower case (i.e. "D&Twtf?123")
f) Min passphrase length: 30 digits which can be case insensitive alphabetical only (i.e. "my name is death and taxes and death and taxes is my name")

Understand NIST is a US government agency so their exclusion of an algorithm doesn't mean the algorithm is insecure it just means that governments like everything in nice neat packages.  Still there is nothing wrong with following NIST requirements, they just are a little restrictive.

Reference NIST publication 800-132 (Dec 2010)
http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf


Another potential source for "how to do it right" is the Bitcoin wallet source code.  The Bitcoin wallet doesn't store passwords but it does derive the encryption key from the user supplied password.  
It uses PBKDF2 using SHA-2, 256 bit key, tens of thousands of iterations (exact # depends on computing power of wallet).






Notes:
* The entire MD series of cryptographic hashes and SHA-0 are horrible insecure at this point and no new system should even consider them.  Legacy systems should have implemented hashing algorithm upgrades roughly a decade ago.  SHA-1 is cryptographically weakened but faster than brute force preimage attacks against the hash are likely more expensive than brute forcing the passphrase in all but the strongest passwords.  Still given the number of secure alternatives no new project should deploy SHA-1 at this point.

**  NIST recommends 128 bit although that likely is future proofing.  As long as salt is reasonably random and used on a per user basis even 32 bit salt will prevent the attacker from performing any precomputation or parallel attacks.

*** One problem with SHA-2 and similar algorithms is that they are designed to be very fast.  A single high end GPU can perform a billion hashes a second (remember in Bitcoin "1 GH/s" is 2 billion SHA-256 hashes).  This is useful in some applications like HMAC where you need to sign every packet individually as this may mean millions (or potentially hundreds of millions) of packets a second.  On the other hand this speed works against password security.  Unless your website needs to login millions of users per second, every second until the end of time that high speed offers no advantage but it does offer the attacker to attempt a massive number of potential passwords each second.  Strong key derivative functions provide a mechanism for increasing the amount of computing resources necessary to complete a single hash.  If you make a hash take 1000x as long it has a negigible impact on a webserver but it cuts the throughput of an attacker by 1000x.  Imagine an attacker with a given set of resources could break a particular passphrase in 9 hours, 1000x is one year.

Wait who is using MD5 in 2013?  

Error by quoted user.  Site reportedly uses SHA-2.

A hard fork will be necessary and one will want to proceed in a cautious manner to protect the integrity of the network and ensure users are not exposed to any unnecessary risk.

Here is an example of how the process could occur (version # for both clients and blocks in this example are arbitrary and just used for illustration purposes):
1) Test this process from start to finish on testnet.
2) In a future version of Bitcoin client (1.0.1) add support for new block version (version 2).  By default mining nodes will still create version 1 blocks at this time.  In 1.0.1, ver2 blocks >1MB height they are flagged as non-standard and will warn issue a warning to the node, store the block and NOT exclude these >1MB blocks when making the best/longest chain selection.
3) Have users upgrade to 1.0.1.  Monitor the usage of 1.0.1+ versions of clients and wait until a super majority has upgraded (no technical number but 80%+ has been used in the past).  
4) Once super majority of nodes have upgraded set a cutoff date and use alert messages to warn older clients to upgrade or risk being forked off the main network.
5) After date in step #4 have miners begin to create version 2 blocks (but still soft limited to 1MB). A config flag can be used in 1.0.1 version of node to force the node into version 2 block mode (still soft limited to 1MB).  This ensures all nodes have the ability to run the same codebase but still preserve their ability to support or not support the new block version.
6) Decide on a block height to implement >1MB blocks.  This should be 10,000 to 20,000 blocks beyond current block height.  It would make sense for it to be a memorable number, for example if we were ready for the transistion today (block height 246,242) the change could occur at block height 260,000
7) Release a new version of the client (1.1.1) which above the block height decided in step #6, allows creation of ver 2 blocks >1MB and considers them standard (selected for longest/best chain).  Version 1.1.1 would remove support for block version 1.
Use alert messages to warn nodes on versions older than 1.1.1 that they risk being forked off after the block height in step #6.  As the block height approaches the messages should occur more frequently and with greater urgency.
9) The prior major version 1.0.1 can be coded with a failsafe node.  Since it "understands" ver2 blocks and just considers >1MB non-standard it can use this to protect the user.  The version 1.0.1 can be coded to look for double spends in the >1MB blocks.  The node can also count the # of blocks received on chains marked non-standard (because they have 1 or more >1MB block) and if that exceeds 50% of the total blocks in the prior day the user has likely been forked off (because it is after the cutoff date).  The node could then consider all transactions unconfirmed, prevent spending, and warn the user to immediately upgrade to avoid loss of funds.  Users older than 1.0.1 would have on knowledge of version 2 blocks and are at greater risk however similar safe mode could be built into clients now which looks for >50% of blocks being future blocks versions.

End state (once the block height picked in #6 passes):
Miners can (but aren't forced) to produce blocks greater than 1MB.
All nodes on current version will see these larger blocks as valid and use them for selecting the best chain.
Nodes which are on obsolete versions have some protection against malicious attack (alert messages & fail safe mode).

No it isn't a particularly simple process and it will take some time but using a staged process like the above (just an example nitpickers) provide a transition plan and ensure both non mining and mining nodes are ready for the change.

Please cite the law which makes selling Bitcoins by PayPal funds a criminal activity.  Cite the exact statute.  Not your belief, or something your friend told you, or PayPal's TOS (which are not criminal statutes).  You can't because (and apparently this is a very difficult concept for you to grasp) IT IS NOT ILLEGAL.  Period.

Now PayPal's network is the private property of the PayPal corporation and as such they can set rules on their use of their property.  This is no different than you have rules on what you let go on in your house (like never inviting D&T to dinner).  You broke PayPal's rule and got caught and PayPal has taken action against you.  However violating PayPal's TOS isn't in itself a crime.  

I've also seen a stink about the price being too high.  People either believe in free markets or they don't.  Are they selling out?  Yes then the price isn't too high.  If the price is too high then they won't be able to move units at that price and they will lower the price.  Right now ASICMiner faces minimal competition.   Avalon has sold a lot of chips but not a lot of complete units.  If/when Avalon board builders start to sell in bulk and <gasp> even have units available for immediate delivery ASICMiner will be forced to lower their price ... or they won't sell anything.

Trust the power of open fair markets people.

I think the confusion is from incorrectly using the term "illegal".  It is legal and it is also legal for PayPal to freeze transactions and/or accounts that are in violation of their TOS.

Closing an account is one thing, confiscating funds without due process is a whole different ball of wax.

Frozen or banned it doesn't matter, PayPal can't and won't just "keep your moniez".

The funds will either:
a) go to law enforcement based on a seizure warrant (highly unlikely in this case)
b) be (partially) used to cover chargebacks and refunds (hopefully your other prior recent customers don't learn of this and decide to get a risk free "refund")
c) be refunded to "you" after 180 days (well the name on the account hopefully it is real)

If these are really your accounts in your names (or your "partners" names) then you should receive the net balance (minus any chargebacks and reversals) in 180 days.  If banned and not just frozen you will never be able to open a new account again.  The "good news" is that forming a corporation or LLC is pretty trivial (some states even allow you to do it online) so you can always open an account in the name of a business (LLC or corporation) where you are the sole member/owner/shareholder.  

Make up a bunch of nonsense about proof that Bitcoin is the mark of the beast then plaster it with adsense ads and get rich off bible thumpers?  For a bonus helping of irony use your adsense checks to buy more Bitcoins.

"Im new, whats easy methods of getting US dollars.  I would like some more US dollars and want to find an easy way to get a lot of them in a short period of time with little or no risk."  Silly huh?

If currency is easy to acquire then the value (purchasing power) of one unit of the currency is lower.  Units of currencies are always arbitrary.  Which buys more ~10,000 Yen, $100 dollars or 1 BTC?  The nominal units is meaningless what matters is what you can acquire (wealth) with those currency units.  Currency (and money) is merely an accounting system for wealth, it isn't wealth itself.  If you could acquire currency easier than you could acquire other forms of wealth it wouldn't be a currency (or the exchange rate is incorrect due to immature markets).

However with the "I never lose at gambling" comment my guess is the OP is merely a method to drive interest in an amazing "never lose gambling system" he will be selling in 3, 2, 1 ...

You could.  Understand that you can't force the original chains to stop functioning so someone who has 1,000 xCoins would still have 1,000 xCoins in the existing fork AND 1,000 newCoins unless the user does something to destroy the xCoins.  Remember there is no off switch to a blockchain.  Even if the original developer(s) quit the blockchain will still continue (and thus coins will still be usable) as long as there is a single mining node.   Case in point Satoshi left the Bitcoin project.  Today Satoshi couldn't "stop" Bitcoin and force everyone to upgrade to newCoin. 

There are a couple of methods you could use depending on what you are looking to accomplish.

Method 1: Snapshot of existing chains (simplest)
To save space the developer would decide on a "cutoff" block for each of the existing chains (and make this publicly known well in advance).  On the cutoff block, analyze the blockchains and record the UXTO ( the unspent transactions) as of the cutoff block.  This can be considered a pruned version of the full blockchain (for example Bitcoin blockchain = ~9GB but UXTO is ~240MB).  In the genesis block of the newCoin record the UXTO set for the merged coin(s).  If users are willing to partially trust a central authority in the bootstrapping process you can compact this by reducing the UXTO to just a ledger (public key hash and balance) which would be about 24 bytes per address (not output).  I call this partially trusted as any user who wishes could validate the ledger using open source software to ensure it matches the UXTO at the time of the cutoff block.  If enough users independently validated the ledger it would have robust "enough" security.  An attempted fraud would kill newCoin in the craddle, what you really want to avoid is nobody double checks and 5 years from now when newCoin is worth a fortune someone realizes someone snuck in a bonus 10,000 coins.

So for Bitcoin (as of July 2013)
Full blockchain = ~9,000 MB (~3 million spent and unspent transactions)
UXTO = ~250 MB (~800,000 transactions with unspent outputs)
Compact ledger of UXTO = ~13 MB (~600,000 funded addresses)

Method 2: Destroy coins on existing chain prior to genesis block (more complex)
 Now like I said xCoin, yCoin, zCoin will still exist.  Once launched in the wild you can't "stop" a cryptocurrency (that is kinda the point).  If you wanted a person getting 1,000 newCoins to no longer have 1,000 xCoins it is a slightly more complicated process.

The simplest way would be to require users of xCoin, yCoin, and zCoin to destroy their coins by sending them to a "dead end" address which is one where the coins are provably unspendable.  This would need to be done BEFORE the launch of newCoin.  You would set a cutoff block for xCoin (and yCoin, zCoin, etc).  After the cutoff block you would locate all the "destroyed" xCoins and premise an equivalent amount directly to addresses the user controls in the genesis block.  So a user with 1,000 xCoins would provably destroy them BEFORE the cutoff.  After the cutoff the genesis block for newCoin would be created which has 1,000 coins newCoins going to this user.  The obvious advantage over the prior method is no duplication of coins.  1,000 newCoins = 1,000 xCoins destroyed.  The obvious disadvantage is that users would need to destroy their xCoins before newCoin launched which is a risk and some may not (either don't like the risk, don't learn about newCoin until after cutoff, etc).

Method 3: "transfer" (well technically destroy & create) after genesis block (more complex)
The major disadvantage over the second method is that you are forcing users to make a choice before the launch of the new coin. If you want to allow "transfer" of coins from xCoin to newCoin AFTER the genesis block well it gets more complicated.  Nodes would need to run a node for both newCoin and xCoin (and yCoin and zCoin etc).  You could have a special transfer transaction where users would send their xCoins to an "dead end" address (one which is known to be unspendable) and simultaneously create a "transfer Coin" transaction on newCoin.  A miner would need to validate this across both chains (that user destroyed their coins on xCoin AND user made a createTx on newCoin and the two are linked). The obvious disadvantage of this is that newCoin now relies on nodes running both newCoin AND xCoin (and yCoin, zCoin, etc).  You could limit this for a certain timeframe.  For example transfer Tx are only possible through block 100,000.  This would allow nodes to stop running the older coin nodes after block 100,000.



Notes:
For simplicity I just used 3 chains and a 1:1 relationship (i.e. 1,000 xCoins = 1,000 newCoins and 1,000 yCoins = 1,000 newCoins).  This isn't required.  One could easily implement different ratios depending on number of coins outstanding for each chain (i.e. 1,000 xCoins = 100 newCoins and 1,000 yCoins = 5 newCoins).

You could combine these methods if you wanted to.  For example maybe one chain has enough support that you go through the more complex process of allowing method 3 but for 6 other smaller chains you just use method 2.  Another example would be to combine methods 1 & 2 with different ratios.  i.e. if you destroy your xCoins you will get 1 newCoin for 1 xCoin however as a backup the UXTO is also included in the genesis block so even if you DON'T destroy your xCoins you get 1 newCoin for every 1,000 xCoins.

Then stop being tired.  Nobody asked you to do any research.  You made an unsubstantiated claim.  When asked for a cite you linked to something completely unsupporting.

I will take your claim of SHA-2 being broken this year (as if such a thing is even predictable) as utter nonsense.  See your done.

No none of that is correct.  Transactions take up space ina  block.  On average a tx is roughly 250 bytes.  The actual size of a single tx will vary depending on the # of inputs and outputs but looking at a large number of transaction is aggregate they average around 250 bytes.  Currently the Bitcoin protocol limits blocks to 1MB.   1024 * 1024 / 250 = ~ 4200 transactions.  4200 transactions every 600 seconds = ~ 7tps.  As pointed out above the 1MB limit is arbitrary and can be raised in the future.

None of this has anything to do with the number of hash attempts miners need to make before solving a block (failed hashes are simply discarded).

Exchanging Bitcoins for PayPal funds is not illegal.  It may be against PayPal terms of service but then again so is having 6 PayPal accounts.
As for bitmit doing something illegal have you read their terms of service, you know the terms you agreed to upon signing up.

Not sure if you can't read or you think this says something it doesn't.  Nothing in there about SHA-2 being compromised this year.

Yeah rainbow tables can't be used BECAUSE sites employ the use of strong random salt.  If you passwords aren't salted then you are vulnerable to this much faster form of precomputation attack.


Nothing in there about not salting passwords.


Nobody said salt = "magic solve all your security problems" bullet.  However properly employing salt does make the job of the attacker harder.  They can't precompute, they can't use rainbow tables, they can't check all entries in password table simultaneously.  If your passwords is weak or known they can still break it but they have to do it the hard way.  One hash at a time with no speed ups. 




Um bcrypt is a salted hash.  Are you dense?




Thank you by your logic you are "an idiot, no exceptions".

It was more a "why", why make it more insecure than necessary?  Proper password security also protects your users if the site is compromised and users (being users) ended up using the same password on multiple sites, possibly even your other sites.

Care to clarify?  The purpose of salt is to prevent pre-execution attack (i.e. rainbow tables).

There is absolutely no reason not to salt passwords as in no possible way would it reduce security.  It limits the attacker to one attempt on one account per operation which can never be slower without salt.  Furthermore many key derivitive functions like bcrypt have integrated support for generating and storing salt.  It no requires no additional work. 


I take it bitcoin-central doesn't salt passwords to protects users?