Ah, you started with the retail terminal scenario; I started with the scenarios in use today thinking it could be expanded to those if the cost could get down low enough.

If I were to start with the terminal scenario I would have still do a smart card for form factor and cost reasons; implementation wise I would do a custom card applet that implements the bit coin wallet, communicated with a secured pin entry device (ped) or had onboard display and input mechanisms.

The approach you mention would work but I don't know if it could ever be scaled out to a currency card in a cost effective manner.

That said our two lines of thinking are compatible.

I've thought about it many times.  It would be so easy, and it would be crazy how much I could do with an exchange that had some integrations with the pool to facilitate fast sells/buys.  After dealing with how to scale these pools, the kind of traffic an exchange would get is nothing.

However, I simply don't know what kind of legal trouble it could cause running an exchange, since I live in the US.  And there is no way I could keep working my day job (which I do enjoy, most the time) while running this pool AND an exchange.

I've been thinking about wallet security too.  I think a second device is a good idea, but I see it working in a different way.

I see a portable dedicated device with very limited communications ability.  Just a serial port will do, which probably means serial over USB or serial over bluetooth.  It will also have a SD card socket for wallet backups.

The device will generate the key pairs, and store them.  The private key never leaves the device, except on the SD card backup, which could be encrypted.

I think it only needs 3 hooks into the PC client software.

1) It needs to be able to push public keys to the client.
2) It needs to be able to ask for (and receive) balance updates from the client.
3) It needs to be able to accept an address from the client, and generate a complete transaction to that address using an amount entered on a keypad.  (Or possibly accept an address and amount, then only ask for confirmation.)

I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.

I'm thinking Arduino.  It should already have all of the crypto libraries necessary, plus hookups for serial, USB, BT, and SD cards.  Probably going to order some hardware this week to get started.

Do you know what happens to bank accounts after seven years of inactivity?

The stability of a system where 10 million coins are in circulation and no more than 1 million are unaccounted for is much greater than a system where 1000 are in circulation and 10 million are unaccounted for. By unaccounted for, what we mean is, are they lost or being saved? We cannot know.

If 1000 coins were in circulation right now, we know that about 6 million are saved, as opposed to lost. This is a reasonable assumption. This assumption must become murkier over time. We do know that coins will be lost, until every coin is lost. But we don't know the rate, nor will we ever have a more accurate estimate of it than we do now.

What we know for certain is that our estimate of the ratio of coins in circulation compared to the number of coins either saved or lost is guaranteed to become less accurate over time. In its extreme, that ratio approaches zero. And when that ratio is near zero, the currency is unusable.

Oh no no no no no you got it all wrong.  See, someone saves 10,000 coins for 10 years, finds them and then BAM!! instant market imbalance!!  

/joke

There may be merit to what you're saying, but are you positive it is addressing this scenario:

The problem is that the ratio of saved coins to lost coins becomes less knowable over time, while at the same time, the ratio of coins known to be in circulation to the coins that are currently not in circulation (lost or saved) becomes smaller and smaller, which leads to a system that becomes, at the extreme, so uncertain that it is unusable.

You can get a good idea of how many are in circulation, but as time progresses, you will have less certainty of how many are saved vs. lost.

Let's assume it's the future and all 21 million have been minted. Let's assume that we see 14 million in active circulation and 7 million that aren't circulating. Are they lost or being saved? Valuations will be less accurate over time. I don't see how they cannot be. Imagine valuations based on the assumption that they are mostly lost, and then have them dumped on the market from a dormant account.

Over time, there is a guarantee that bitcoins will be lost, but there will be no real way to measure the average loss over time. Requiring a heartbeat eliminates that problem and allows valuations to be more certain over time.

More importantly, and perhaps most importantly, the accuracy of valuations over time based on circulation will be relatively constant.

The system as it is now is designed to allow commerce and valuation to occur, assuming that valuations are based on the collective wisdom of the crowd, which is based on the notion that most all coins are not lost.

not all payments are due to personalized requests.

the best solution would be a field that can be filled with any data encrypted by the receiver's address public key.

Your right, 2 years later $55,000 wouldn't be as much. So it has become very common place to have standard of living adjustments while working at companies currently.

And I don't think you are understanding what I am saying. In order to combat deflation companies would either need to adjust your pay, (pay you less every year) or fire you and hire someone new for less money. If you read my original question I give the example of, if someone pays you 10 bucks an hour and inflation hits at 10% a year. Why, in 10 years time, wouldn't your employer fire you and hire 10 other people at 1 dollar an hour? The only other option for the employer that I can think of is it would be common place to pass out a standard of living adjustment and pay you less every year. That or labor would start to get underpaid in order to counter act deflation and keep employees. Either way it doesn't promote employment longevity and job stability. It seems to be the same problem as inflation just in reverse. 

as you can see above, it is not.
that's like saying the SEPA account number is the reference number, because the receiver could open an account for each payment.

people obviously would like to publish their address for more than one payment but still be able to identify payments aside from the payed amount.

edit: the (important) difference is that a reference number can be freely assigned by the sender, not be generated by the receiver.

Bitcoins are only division down to 2.1e15 units. Changing that is no less difficult than increasing the total BTC count from 21 million to 21 billion, or making it infinite.

why doesnt the bitcoin protocol include a reference number?
I can see why you don't want the size of transactions to get out of hand because they are distributed, but a simple reference field similar to SEPA would be nice.

Petition to FREE KEVIN!!