This is just my purely subjective personal opinion but if I had a wallet with $100,000+ in it I would store it on a computer that had complete air gap security - not even an RS-232 link to an Internet-connected computer. I would want the ability to create offline transactions by hand-keying in the source and destination addresses and would broadcast the transaction by having the offline computer print a hard copy that another computer could scan in and upload to the network.

Thank you for reminding me about another "attack vector" that I neglected.

You'll also need to store the Armory source code as well as the source code of its tangled mess of dependencies, including the toolsets required to rebuild them. Or just buy a life insurance policy and a performance bond on Mr. etotheipi.

Sorry, but I have a feeling that explaining certain long-term attack vectors will look to much like a personal attack. I really don't want to go into that discussion.

I love Armory, and I think it is the easiest possible solution for much of the current bitcoin crowd, but I think the time is approaching that we'll need to begin developing for our parents and less-tech-savvy friends.  I know lots of people, even among my cohort, who don't have spare computers sitting around, and even if they did they wouldn't be able to setup an offline Armory wallet.

Edit:  BTW, you've got PM.

Flexibility is nice but it also means more potential ways for a remote attacker to find an exploit. The lack of flexibility in a specialized device is a feature because it greatly reduces the attack surface.

It might not be worth it for $1000 but a wallet with $100,000+ is a highly desirable target for someone to go after.

If users really are storing $100,000+ there's no reason to use a general-purpose computer as an offline wallet. It seems like a dedicated hardware device should be able to be produced for less than the cost of two USB to Serial converters plus a PC. All it would need to do is receive unsigned transactions, wait for user input, sign the transaction, and return it.

@etotheipi

The offline computer can have an offline antivirus, anti-malware, anti-rootkit software installed. It is updated by virus definition files offline through the USB. Serial cables (as in the RS232?) are non-existent on modern computers and you can consider them obsolete.

Personally, I don't have enough bitcoins to justify an offline computer for the purpose of cold storage, and I think I know relatively enough about malware to prevent it from affecting my daily computer usage despite not having installed anti-virus software (they slow down my computer so much that I notice it.)

Your software is interesting though and I might just download and try it out.

This may be a way to improve the encrypted wallet format.   Passphrase to key function ->  key.  Then have the client encrypt separately a "test string" and the wallet.

This would allow brute force recovery in a secure manner.  The person could just give only the encrypted test string (which given the right key should decrypt to a known value (something like "Bitcoin Wallet format v1.2") to recovery team.

It wouldn't simplify the attacker's job but it would allow forgotten/incorrect passwords to be recovered in a manner that doesn't require the owner to trust a third party.

Just out of curiosity is there any theoretical way to put another password on a file before handing it off to someone yet still have them able to know if they've found the original?

Update OP?

In fact, Startum does eactly what you seem to want to do both decentralized and without an alt-chain.

While this is true, it's far from a complete picture of the intergrated security model that full nodes have access to.  In order for a lightweight client to accept a payment transaction, it must either 1) have Internet and access to a supporting server or 2) accept the evidence that the sender's client provides.  Although a lightweight client sending to another should have no problem sending a copy of the input transactions, which the lightweight client can then verify that it fits into it's own claimed spot on the merkle tree connecting to it's own copy of the block header, this is still not quite the same as what options of verfications that a full client has.

I don't see that, sorry.

And it's quite literally impossible for lightweigt clients to have the 'same confidence as" a full node.  The best that a lightweight client can have is some confidence.

It certainly doesn't hurt to talk about it, but I don't agree that such an idea has merit when compared to other methods od achieving similar goals already discussed.  And if I can't see it, I'f wager that there are many more who are going to be sceptical of it's value as well.  Without a minimum critical mass, nothing is going to matter.

Perhaps, but only if the benefit to the network is demonstratable as compared to alternatives.  While a p2p solution might be possible, it's not always necessary.  And if it's not necessary, it's not likely resource/economicly justifiable.  Bitcoin is p2p for sound reasons, but what reasons carry over to what amounts to a tracking service?  If the server that a particular client chooses should go down or be DDOS'ed, the result from the perspective of the user is the same as if he had left his service area; a temporary inconveince.  And in the case of header-only/lightweight clients, not necessarily even a dehibilitating one.  I'll admit, this idea has merit; but it seems to lack encentive.  I can admit I might be overlooking something here, but what gain does a miner have for participating and sharing his findings?  Both are important, because if his gains are personal, he then has limited incentive to share the results.

  Not sure that this is a good analogy, since there would be economic incentive to merged-mine both chains.

Although this is an interesting idea, I don't think that it's viable.  How do you encentivise miners to secure this alt-chain? 

However, a running balance table server isn't a bad idea as a pay-for service for light clients to use as a means to check their own addresses to make sure that they havn't missed something.  For example, one (or serveral) balance servers could exist that individual lightweight clients could contact out-of-bitcoin-band as a quick check upon startup, or a secondary check.  If the balance returned does not match, the lightweight client may have to try again, but if the balance returned matches what it thinks that it should have upon startup, the client can happily assume that it has all the relevant transactions to continue.

The service could be paid for in an anonymous, monthly fee.  Once every 30 days or so, the client tries to send the chosen balance server a small tip, and the server collects the addresses presented in that transaction (since lightweight clients tend to use fewer new addresses, or a more sophisticated lightweight client for the desktop could simply create a special transaction that uses as many input address as may be important, or simply uses the monthy transaction to consolidate addresses into a new operating address producing the server's monthly fee in the process).  When the client is restarted in the middle of the month according to the datetime available to the client, it first checks to see what it thinks that it's balance is, and then sends off the appropriate requests to the subscribed balance server.  If the server responds with the matching balance, the client happliy can quick boot and be ready for action (like bitcoinspinner).  If the balance returned is differnet, the client then should tell the user that it needs to update itself before spending, and proceed to do so in the background.  If the server feels it's not been properly paid, it returns an error code; or of the address is unknown in the blockchain; which would likely be the same as a zero balance to a running balance server.  Lightweight clients (that hold block headers) could still manage local transactions sans live Internet access, but with a warning to the user that Internet was not present and this could present a risk.  This setup would allow android clients to get into a working condition as fast as BitcoinSpinner most of the time, while also permitting delayed transactions/offline transactions to occur, which BitcoinSpinner & BitcoinJ most certainly cannot do.

This will not come to pass.
Way too complicated indeed.