As someone already pointed out, the number of coins is near-constant, so you will have little, if any, effect on the rate of inflation.

You will eat some sell orders, however, the coins you would have mined will now go to someone else who will probably put them on the exchange, so you aren't affecting things as much as you think.

By lowering the difficulty of mining you are weakening the network.  Not by very much, but it does make it slightly easier to attack.

The average person doesn't know or care the details about cpu vs gpu, but that doesn't make it immaterial.  If someone hears about bitcoin and looks into it, they will quickly realize that mining is impossible, they have no choice but to go to the exchanges.  A cpu friendly coin will allow more people to be able to actually mine coins.  It is much better for someone who is just learning about a currency to be able to play with it for just a few cents in electricity.

It won't surpass Bitcoin, it is too similar.  It might be able to co-exist though.  The only real advantage is that people without super graphics cards can get coins,  if there are enough people in that situation it should be ok.

Having different rules make it seem more like an entirely different network than a testnet, it also makes it less effective as a test platform.  Would it be possible to automatically reset it once a week?

At least he used descriptive variable names.

Which brings us back to the original question,  how come litecoin doesn't scale the processing power and memory usage over time.

GPU's already have 1 to 2 gigs of memory on the card, and they are very good at streaming data.  Yes, scrypt uses random access to limit the benefit of the streaming memory, but that really only adds latency.  Even if GPU alus don't get enough cache in the future, threading would let you hide the latency by having more processes.

Take the extreme case, lets say litecoin is around in 15 or 20 years, are you really convinced that GPU's won't get cache or threading in that time?

scrypt is designed to scale in both processing difficulty and memory use,
however, litecoin doesn't seem to have any way to change either. This seems like a big oversight, in a few years it won't be so gpu unfriendly.

For the salsa 20 hash, litecoin uses the 8 iteration version.  There have been identified attacks for 7 rounds, this doesn't leave much margin of error.  The 12 round variant seems much safer.

Anyone know why these choices were made?  Are they just copied from tenebrix?

Thanks.  I that clears up a lot.  Can you change the outputs or are they required to be the same?

They seem to have the same list to me.  Newer versions have additional entries but once on the list they don't seem to change

List from 0.3.19:
nHeight
11111
33333
68555
70567
74000

List from 0.3.23:
nHeight
11111
33333
68555
70567
74000
105000
118000

I think I'm beginning to understand this, tell me if I have it right.  A output can only be spent once, thus, if two transactions spend the same output (as one of their inputs) then they count as the same transaction. So if you had two transactions:

T1:
Input1,Input2 -> Output1

T2:
Input1,Input3 -> Output2

They would both be considered different versions of the same transaction since the both share Input1.

If you had a transaction
T3:
Input1 -> Output1 with a lock time that was non-zero and greater than the current block number then that transaction then that transaction is still open, you would be able to broadcast a replacement transaction (with a higher sequence number) and change the output or the script  (or both) to whatever you wanted, but you couldn't change the input.

(I realize this isn't all implemented in the client, I'm just trying to figure out how it will be done when devs get to it.)

Coins get created with new blocks, not new transactions.  They can even be created with no transactions (except the coin generating one) in it.  The only thing miners get that is associated with a transaction is the fee and that fee comes from the person sending the bitcoins (the borrower in this case).  Sorry, no free lunch.

They really are a type of currency, people don't think of them as such because they aren't freely convertable, you're pretty much stuck using them on airfare or some fairly limited catalog of products, but companies (like credit card companies) buy them from airlines to give out as rewards.

Amazon could start a new blockchain then give the coins out as rewards points.  You could then redeem them for money off on your purchase. They could also sell them to other web sites, you buy an airline ticket and get X amazonRewardPoints.  Since it is based on the blockchain, any partner could verify the number of points out there.  Also, they could accept points knowing they were free to re-distribute them and that Amazon was effectively fixing their value.  Pretty soon you'd have a large network of merchants both giving out and accepting points without having to trust each other not to create an arbitrary amount of points.

I doubt you'd ever see a government agency using it to record legal records.  You might be able to use it for contracts though.  You could encode the contract conditions right in the message. (I know there is a thread about contracts going on now for regular bitcoin but I think it requires you to specify the contract out-of-band).

Lots of questions here.

"Why would they need to know?":  There is a field in the transaction to say it is an updated transaction.  If that is to be useful, you have to know what transaction is being updated.

"If you changed everything in the transaction, what difference does it make whether it's updated or new?" If it is updated then the old transaction wouldn't go through, if it is new then the old transaction  could go through too.  I wouldn't expect people to change everything , even if they changed one of them how would you tell that it is updated?

For example:

You change the output: how do you distinguish it from a double spend attempt.

You change the input(s): how do you distinguish it from a second transaction to the same output?

I don't think so.  Namecoin doesn't include the suffix, .bit is just a convention.  Of course, since it can store arbitrary key value pairs and the key portion has a specifier you could create a new, slightly different DNS that did have suffixes.  That would probably cause more confusion than it is worth though.

Nothing prevents other virtual currencies from coming up.  There will probably be multiple ones based on bitcoin.  Bitcoin has first-mover advantage but if a new one comes along with a large enough advantage over bitcoin then it could take over.

The protocol https://en.bitcoin.it/wiki/Protocol_specification includes a lock_time field for transaction (bitcoin doesn't currently implement it), the description from the wiki: "The block number or timestamp at which this transaction is locked, or 0 if the transaction is always locked. A non-locked transaction must not be included in blocks, and it can be modified by broadcasting a new version before the time has expired"  Then in TXIn there is a field for sequence, describe as: "Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block."

What is unclear to me is what changes to a transaction would be acceptable in an update, could you change the source coins, the destination address, the script?  And, if they are changed, how would miners determine that this is an updated transaction and not a new, totally different one?

You seem to think that you are using a currency system with a contract that states the rules are fixed and will never change.

You should re-read the rules of bitcoin because you have missed a big one.  The rules are set by a majority of the miners (with the consent of the majority of people sending/receiving transactions).  If the majority of users vote to change the rules (by using software that implements new rules) then the rules are changed.  You know (or should know) this and implicitly agreed to it (by using bitcoins), it is part of the system and has been from day one.  Your bearer certificate example is simply not relevant.

Just to be clear, Namecoin has the features of bitcoin (since it is a fork of bitcoin) plus the distributed data store, you wouldn't back bitcoin with namecoins, you would use namecoins instead of bitcoins.

It wouldn't completely solve the liquidity problem but it would help,  if you want something other than names, like food, and if you were having problems getting people to accept namecoin for food, you could sell it to someone who does want the naming feature and buy food with the proceeds.