Greece or some other sovereign nation is adopting Bitcoin as legal tender. Bitcoin will trade on FOREX.

Yep. If pretty much everyone (say, more than 3 Billion ppl) is using Bitcoin, then there is less than 7 milliBitcoin for everyone. Thus BTC 100 will be a fantastic amount of money.

The decrease of prices (the term "Deflation" is IMHO not adequate) is caused by the growth of the Bitcoin economy (ignoring speculative bubbles) - either new users entering the Bitcoin economy or old users increasing their use of Bitcoin. Assuming a 10% decrease in prices therefore assumes a 10% real growth. Assuming that most people are already in Bitcoin, this will have to be mainly increases in efficiency. Which doesn't seem right.

While price is unstable, Bitcoin will be used as an intermediary currency, quickly bought and sold to purchase goods or services whose price is stable in another currency.  While Bitcoin deflation is rapid, it's other use will be as a value store. An rapidly inflating coin would be either unused or highly circulated. A quasi-stable, slowly deflating coin seems to me to be the steady-state for Bitcoin in the long term, should it survive.

That's you and your personal preference and also irrelevant to the whole market. Those who will want to deal with a currency that gets worth more over time will find a way to solve this "problem". Perhaps a solution is to peg the wage contract to some amount of purchasing power instead of a fixed amount of currency.

...Perhaps I should also add a way of opening the Options page from the popup?

Hi all,

I've published an initial release of a Chrome Extension to manage a bitcoin wallet in most ways similar to the Electrum client. So far I've been the only one testing it, so I'd appreciate some initial feedback. The extension is available here:

https://chrome.google.com/webstore/detail/hfdeddmpdncodjalbadbanlcombfeoll/

The code is on github here: https://github.com/andreyf/electrum-wallet-chrome-extension. I haven't decided on a license, but it'll probably be GPLv3.

I would appreciate any criticism/feedback you might have. Feel free to e-mail me at anfedorov@gmail.com.

Cheers,
Andrey

Worked great. Thanks.

Oh, I didn't even know that you can run Android apps on the kindle.
I just uploaded the latest signed apk here: http://code.google.com/p/bitcoinspinner/downloads/list
Let me know whether it works.

Isn't it easier if the receiving party just generates a new keypair?

You cannot take an address and make a new address that the same private key can use, correct? But this is just because of the hashing going on, if we used pure public/private key pairs that would actually be possible?

Regarding identifying the sender generated keys. The sender could notify the receiver out of band, right?

Here it is - 1D5yADZsb1XGE15rbBRWhe2QkRDGSv3588

FYI, this topic has been discussed in a few different contexts, such as in this thread.  Obviously, multi-signature transactions are built into the network, so this kind of ECDSA magic is unnecessary, at least for simple 2-of-2 transactions.  Also, the 2-of-2 using ECDSA as you described requires one party to compromise their own private key to allow the other party to claim the entire encumbered amount.  There's no way to, say, split the money that is locked in the 2-of-2 transaction without one party trusting another.  Also, I don't like the idea of having wallets where some private keys are supposed to be revealed, while it's an epic fail for other keys to be revealed.  It works for Casascius physical Bitcoins, but I have personally decided it's not a good idea for general usage.

On top of that, I believe that being able to split the encumbered money is important:  I am firm believer that both parties need a "risk deposit."  That the initial 2-of-2 fund is seeded with, say, 20% of the transaction value from both parties (can do more or less depending on how much the parties don't trust each other).  At the end of the transaction, if everything went as planned, both parties get their risk deposit back -- Alice puts in 1.2X and Bob puts in 0.2X;  at the end of the exchange, they both sign a tx sending 0.2X to Alice, 1.2X to Bob.  But if it doesn't go smoothly, then both parties lose their deposit and the tx money.  Therefore, there is every incentive for both parties to resolve the transaction agreeably.  

This avoids:  
(1) Lazy Alice:  Alice receives the goods but then is too lazy to sign the transaction completing the transfer to Bob (or in your case, sending the private key to Bob).  She might do this maliciously if she is disatisfied with the product, and if she has no risk deposit, it costs her nothing to screw over Bob.

(2) Prankster Bob:  Bob advertises that he has products to sell with no intention of selling anything.  Alice puts 100 BTC into a 2-of-2 tx, and then Bob disappears leaving the money stranded.  Or Bob comes back and offers to split the money with her, since she'll get nothing back if she doesn't agree.  Etc.  With a risk deposit, Bob has to put his own money into the tx to demonstrate that he is serious about the transaction.  And using special hash codes, it's possible for both Alice and Bob to inject the money "simultaneously" so that neither party risks putting money in before the other.

(3) The risk deposit could serve as a pre-paid fee for third-party arbitration, if a third-party was included on the transaction.  A common agreement might be that third-party Charles, might arbitrate any transaction that has at least 10% risk deposit from both parties.  Charles takes that 20% as its fee only if arbitration is needed.

Gavin doesn't like the idea of coins being lost, and thinks there should be a MAD option (mutually assured destruction), to allow the coins to be recycled if things go awry.  I'm still not entirely convinced that's necessary, but it's not a bad idea.  I guess we never actually resolved "the best way" to do this...