Too bad! EDIT: kind of proves my point, we didn't need it in the protocol!

You kinda did just there, and that also proves my point!

This isn't about mobile phones.  That is just one example of one possible way to improve security.  There are countless other ways, most of which haven't even been conceived yet.  What they all have in common is that they require a way to divide signing authority so that a single point compromise isn't fatal.

P.S.  If this current single point system works for you, you can keep using it in the future.  It isn't going away.  But lots of people (approximately everyone but you) want the ability to use multisignature systems.

P.P.S.  Loosen your tinfoil cap a bit, and maybe poke some air holes in it.  And I say that as someone that keeps an old Palm Treo working because I don't want Google, Apple or Microsoft to "own" my phone.

To Kjj,   I accept all of your points but as the only one who does not want to change I hope you will accept my right to say that. It does seem that you think multi sig is the way to go and that also reflects gavins point in his original post but in his case I think "everyone  agrees" means the three main developers. Has he asked every one on the bitcoin network (he could there is a way to vote). As a non techie (I know that negates my position) it has been shown that multisig is already in the os program but not used due to bugs. So future development and alternative branches are not ruled out. Also I may seem paranoid to you but I am english and here the police have just trawled millions of phone calls and e-mails stored from the last few years to arrest  Sun journalists for phone hacking. Eventually (my main point) it was yourself who outlined in step by step how a multi sig would work and it looks difficult (to me) and time consuming defeating the speed of current transactions. So please put my mind at rest and do it again for someone like me, an average user who has no mobile, access to only one personal computer and here in the uk internet cafe's are rare and the public library controls access to its database? reg.

I think that the universe of bitcoin users can be divided into two groups: those that want multisignature capabilities and know it, and those that want it, but don't know it.  I'm pretty sure that you are in the second group, even if you think you are in a third group, those that are aware of multi-sig, and really don't want it.  I really, truly believe that you do want it but don't know that you want it, but it isn't something that I'm willing to argue about. 

The example using the mobile phone is pretty common.  I have no idea who first came up with it, but I fleshed it out in detail showing one possible way that it really could work in real life.  But there are other ways to do it.  Most of the other ways to do it haven't even been invented yet, so I have no idea what they will be.

If we want, we can abstract my mobile phone example back a step or two, and come up with something less specific, but still clear (I hope).

Step 1, I tell my client to send 5 coins to address XYZ.
Step 2, my client creates that transaction, signs it with the key it has, then sends it to my wallet service.
Step 3, my wallet service looks up my policy preferences, and since the transaction is more than 2 BTC but less than 10 BTC (my policy), it invokes a verification step.  The verification step involves either me contacting the service, or the service contacting me, using some communication channel other than the one used to communicate the transaction.  This could be a text message on a cell phone, a regular phone call, a personal visit to the local branch office, a telegram, a website, email, a USENET post, snail mail, smoke signals, carrier pigeon, semaphores, chalk marks on mailboxes, etc.  This will be either a little bit slower (SMS) or a lot slower (chalk marks).  You will customize your policy preferences to balance your desires for speed and safety.
Step 4, the communication involves some means of mutual verification, such as challenge-response, code words, photo identification verification, etc.
Step 5, if I am satisfied that I am talking to my service, and they are satisfied that they are talking to me, I can approve or recant the previously sent transaction.  If approved, they countersign using their key.
Step 6, my wallet service now sends my double-signed 2-of-2 key transaction out to the bitcoin network.
Step 7, the bitcoin network checks that the two signatures on this transaction match the P2SH signature that was provided earlier, and the BTC shows up in the vendor's wallet.

This is a basic model that has already been invented, and in the abstract sense is actively used all around the world every day.  The specifics can be adapted in many ways to meet different needs while still keeping some essential features and characteristics.  Other models may also work that accomplish the same goals.

And I want to stress two important things that I think are easy to overlook in this discussion.

First, no one can force you to use multisignature systems.  Even if there was a proposal to modify the network to totally disallow single signature transactions (a change which would be approved by pretty much no one at all), it would be trivial to be your own verification service.  Your computer would run bitcoin, and also run a second program just to approve them.  This could either be automatic or manual.  If automatic, it would be exactly the same as what everyone is using now, as far as they are concerned.

And second, bip16/bip17 are totally not about whether multi-sig is good or not, or will be included or not.  They are about how multi-sig will work behind the scenes.

Jeez, then just don't use it. What was your point again?

But it doesn't have to be that way.  The service doesn't have the ability to spend your money, and if you set things up right, they can't prevent you from spending it either.

Think of a script in a transaction that can be redeemed either with Key C, or with the pair (Key A + Key B).  This is usually called "(A and B) or C".

You generate a bunch of these offline.  Key C is protected somehow and is never in a computer connected to a network, like printed on paper and stuffed in a safe.  Key B goes to the service (or comes from the service, either way).  Key A goes in your wallet.dat.

So, if someone breaks your computer and gets Key A, they can only spend small amounts, depending on the policy you've established with the service, and only until you realize that someone else has your keys and you tell the service to not sign anything any more.

If someone breaks the service and gets Key B, or if the service isn't trustworthy, or if the service is coerced by the government, they can't spend your money because Key B isn't sufficient.  They can stop you from spending it, at least until you go to your safe and fetch Key C, but that would instantly show that they have been compromised.

They are explaining how the new feature will work. You do not need to use the new feature. Your user experience with the system will remain unchanged, unless you wish to use the new feature.

Kjj posted pretty much what I said, except the key I said to pot in the safe would still require the one on your USB key, while in his example the safe key is all you'd need (his is better). This is something that requires a protocol change and can't be done with software.
Regarding a "simple app," it can just be a small program on your USB key that you can run without needing to install it. It only needs to do two things, communicate with the online wallet, and sign cryptographic transactions. You come to any computer, plug in the key, go to the online wallet, send money to whatever address you want, then run the app on your USB key and sign it to verify it.
Currently your only option is to store a copy of the private key in the online wallet and in your safe. Although that will protect you if the online service dissapears (you still have the key to your money), if the online service gets hacked, the hackers can take all your money.