Hiding your bitcoin behind a timelock AND "m of n keys" at the same time?

[coastermonger]

As much as I want to run it, the bitcoin-qt client currently has lax security in my opinion. Protecting any amount of coin with a only a simple passphrase risks many kinds of unauthorized withdrawal attacks, mainly from keylogging malware.    
As this discussion has evolved, it has become more about the security issues with private keys themselves and how to fix them.  Don't get me wrong, the Bitcoin-Qt client is a fantastic wallet that I would love to run on my computer, but I honestly feel like keeping my BTC behind a layer of 2-factor authentication is safer.

One of the biggest fears any bitcoin holder has is that an unauthorized program will clean out their wallet.  It's unfortunate that thieves who are successful at it are very likely to do it again.  There is absolutely no recourse for the vitcim to get their coins back, and currently no punishment awaiting those who perpetrate the crime.  Is it ever totally the victim's fault? It's a moot question.  You can point fingers and play the blame game all you want but the reality is in these kinds of circumstances, thieves will absolutely try to steal coins any way they can and it's BAD FOR BITCOIN.

How can we fix it and especially protect the most vulnerable users?  Cold storage, Paper wallets, hardware wallets, and multi-sig are a start, but believe me when I say they're not enough, they shouldn't be the only options, and many users actually don't have the wherewithal to set them up.  My rule is if you can't trust your bitcoins with grandma, it's not easy enough yet.  Each user should be able to run their own digital trustless BTC vault

What's an easy way to beef up security without trusting other people to hold your coins?  The answer is simple, and built right into bitcoin: time.  Time can be measured two ways, by the computers clock or by the network itself in terms of confirmations.  If we can use scripts to prevent our coins from even being sent out until a specified time or number of confirmations have been made after our request, it will greatly help decrease the chances that our coins are spent without our approval, it will also solve other problems propagated by human error.  

I have five simple suggestions for potentially improving the security of coins kept on any wallet, but especially the bitcoin-qt

• give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time (or number of confirmations) must pass before it is sent out and the request can be cancelled anytime before that.  Even more importantly, many methods of notification should be available to say that a withdrawal request has been made.
• allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.
• allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.
• allow users a kind of "total lockup" mode, specifying a period of time in which no coins can be transferred to a new address in any way shape or form until a period of time or a specified number of confirmations has passed.  Personally I believe this should have a maximum to prevent coins from being locked up for years by accident or malicious intent.
  
• a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

Pros: thieves attempting to drain a wallet of funds will find their attempts hampered.  Even if they know the password (or private key) and attempt to withdraw, they must wait a specified time period and the wallet owner is simultaneously notified with the option to cancel.  Thieves may also find that the wallet is unable to process a request to send the funds to their address, i.e. theirs is not on a list of trusted forwarding addresses.

I think the parameters should be as flexible as possible, and of course optional.  Users should be able to specify whether they want a weeks delay or a 5 minute delay, a 2 BTC daily withdrawal limit or a 100 BTC daily withdrawal limit.  Many other different kinds of rules for addresses can be imagined, but of course users could always choose to generate a normal address, and protected from accepting a transaction with these kinds of extra-restrictive output scripts.  A failsafe should always be in effect as well, meaning that the user pre-defines a trusted address that could accept the BTC instantly.  Thieves would have to hack this as well if they wish to spend the coins instantly, and another still if a chain were set up...ad nauseum.

Cons: Users will have the option of enabling these extra security layers, but may find their coins less accessible if they are not careful.  Caution should be exercised so that coins with ultra-constrictive security options are not created.  

I'm very interest in any comments on this.  Thank you!

EDIT 1: To much skepticism, I have further elaborated how this may be possible to do below in the responses. It essentially involves creating transactions that have more constricting output scripts, some of which may require changes to the bitcoin protocol. Jump to: https://bitcointalk.org/index.php?topic=209409.msg2213559#msg2213559

[1713999402]

1713999402

[1713999402]

1713999402

[1713999402]

1713999402

[1713999402]

1713999402

[1713999402]

1713999402

[Terk]

I have four simple suggestions for potentially improving the security of coins kept on any wallet, but especially the bitcoin-qt

• give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time must pass before it is sent out and it can be cancelled anytime before that.  Even more importantly, many methods of notification could be available to say that a withdrawal request has been made
• allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.  Changing this option takes a significant amount of time to re-set
• allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.  Again, changing this parameter takes time to reset.
• a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

The methods suggested above will prevent your co-worker from sending your coins if you leave your computer and wallet unlocked and go for a lunch break (which you shouldn't do anyway). But none of this will save your coins if you have your computer compromised. Once your wallet is unencrypted, your private keys can be read by any malicious software that is running in your system. All these limitations will affect only a user who will try to use Bitcoin-qt interface, but the malicious software having access to your private keys could spend all your coins regardless of these interface-based limits.

[coastermonger]

The methods suggested above will prevent your co-worker from sending your coins if you leave your computer and wallet unlocked and go for a lunch break (which you shouldn't do anyway). But none of this will save your coins if you have your computer compromised. Once your wallet is unencrypted, your private keys can be read by any malicious software that is running in your system. All these limitations will affect only a user who will try to use Bitcoin-qt interface, but the malicious software having access to your private keys could spend all your coins regardless of these interface-based limits.

I get that part of it is an interface and deep down, the real need for protection is at the level of private keys.  But work with me here: I think I'd really like the option to shield my coins through time and/or number of confirmations somehow.  If unencrypting the wallet is difficult and done through the interface, could one also just put a kind of time delay that must pass before the wallet could even allow itself to be unencrypted?

i.e. let's assume that a malicious program has my password.  Then they have the ability to unencrypt my wallet. But previously when I set up the wallet I configured it to only unencrypt and show my private key after a specified amount of time and/or confirmations.  So the malicious program *can* try to do so, but that period of time must pass, I will get a notification for it, and I will be given the option to cancel such an action.

[Terk]

i.e. let's assume that a malicious program has my password.  Then they have the ability to unencrypt my wallet. But previously when I set up the wallet I configured it to only unencrypt and show my private key after a specified amount of time and/or confirmations.  So the malicious program *can* try to do so, but that period of time must pass, I will get a notification for it, and I will be given the option to cancel such an action.

It doesn't work this way. The malicious software just runs in the background and waits until you unlock your wallet. Do you have a time lock? Fine, the software has all the time in the world. Once your wallet is actually unlocked (by you), they have your keys and can spend you coins. They don't really care about your password.

[coastermonger]

I really appreciate your comments on this.

So given that private keys will always allow instantaneous transfer of coins (unless bitcoin itself is entirely patched) this is the crux of the problem;

We have a situation where unlocked wallets (however briefly so) are vulnerable and able to be attacked by malicious programs.  Yet at the same time the wallet needs to be unlocked and unencrypted in order to spend the coins.  

Is a dedicated hardware wallet really one of the most foolproof ways to go then?

Or is there a way to set up a wallet so that despite being "unencrypted" the private keys still can't be read?  

OR is there a way to show the private key on the computer without it being the actual private key, but it becomes something that a person sitting at the computer could understand as the private key?

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

[grue]

you clearly have no idea how bitcoin operates.

give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time (or number of confirmations) must pass before it is sent out and the request can be cancelled anytime before that.  Even more importantly, many methods of notification should be available to say that a withdrawal request has been made.

how can this be enforced at the protocol level? the wallet contains private keys, how can you reliably delay the transaction?

allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.  Changing this option takes a significant amount of time to re-set

impossible. the only way is by sending the coins to the said address.

allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.  Again, changing this parameter takes time to reset.

impossible to enforce at protocol level

a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

lol

[DannyHamilton]

I really appreciate your comments on this.

So given that private keys will always allow instantaneous transfer of coins (unless bitcoin itself is entirely patched) this is the crux of the problem;

We have a situation where unlocked wallets (however briefly so) are vulnerable and able to be attacked by malicious programs.  Yet at the same time the wallet needs to be unlocked and unencrypted in order to spend the coins.  

- snip -

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

There are 3 possibilities that show a lot of promise for protecting private keys and making it much more difficult for a thief/hacker to access your bitcoins.

Hardware wallets.
Multi-signature transactions
Offline signatures (such as Armory provides).

[Foxpup]

Or is there a way to set up a wallet so that despite being "unencrypted" the private keys still can't be read?  

OR is there a way to show the private key on the computer without it being the actual private key, but it becomes something that a person sitting at the computer could understand as the private key?

The private keys must be readable by the software. It can't send transactions otherwise. Encryption is the only way to ensure that the private keys can be read by the software that needs to read them, and only when it needs to read them, while preventing the private keys from being read by anyone else. Though even that won't work if you've got a keylogger.

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

It's not possible. If someone a) can decrypt your private keys (ie, they know your password) and b) has access to your system, they can steal you coins. The only solutions are to a) keep keyloggers off your system, and/or b) make it completely impossible for anyone to access your system at all (cold storage).

Bottom line, if someone or some program has access to your computer, they can do anything that you can do, including access your private keys and use them to steal your coins (using their own software, if your software has "safeguards" which don't actually provide any real protection). No lock is safe from someone who has the key.

[Terk]

There are 3 possibilities that show a lot of promise for protecting private keys and making it much more difficult for a thief/hacker to access your bitcoins.

Hardware wallets.
Multi-signature transactions
Offline signatures (such as Armory provides).

This.

And of course there is this fourth method which always helps and it's called the common sense.

You don't need to and you shouldn't keep all your wealth in Bitcoin-Qt. Just like you don't walk around the streets every day with your wallet filled with every dollar you have. With fiat money you're aware that it's easy to lose wallet, it's easy to get pickpocketed or get robbed, and you don't carry hundreds of thousands of dollars every day, but you rather have most of your wealth stored somewhere secure (that includes banks). You need to apply the same logic to bitcoin.

Read about cold wallets and put most of your bitcoins into a secure cold wallet. Or better split into multiple wallets. If you have 1000 BTC but only spend 15 BTC every month on average, leave 20 BTC in your Bitcoin-Qt and put the rest into cold wallets. Create 10 cold wallets with 20 BTC each and simply use them to reload your Bitcoin-Qt wallet roughly every month. The rest 780 BTC put into a long term cold wallet which you don't intend to touch until you spend all your short term cold wallets (or again, split it into five separate cold wallets). Put multiple copies of the long term cold wallet in some very secure places (don't rely on having only one copy as things like fires happen).

Just because something is being done on a computer doesn't mean the usual common sense doesn't apply. Your Bitcoin-Qt wallet is only as secure as your fiat money wallet kept in your back pocket. You need to be aware of dangers and be careful, because there are people waiting for the chance to steal from you. Just don't stash everything you have in your back pants pocket.

[coastermonger]

I can't even respond to Grue because he's just one of those guys that tells you that "you don't know anything."  Not helpful.

DannyHamilton reiterates some good points. Hardware wallets and offline signatures are two relatively secure ways to deal with BTC without someone having remote access to your computer.  I'm interested to see where multi-sig transactions will lead, but it effectively just makes more private keys necessary to steal before the coins can be stolen.  It's a useful trick but it doesn't solve the problem that private keys need to be so very well hidden.  

As Foxpup points out: No lock is safe from someone who has the key.  If that's the case then I would contend we need a better key.  What's so special about a key?  Anyone can use it, but how we make it changes how the key behaves in the lock.  Perhaps we can exploit this last property to our liking.

Terk I honestly appreciate your feedback and comments here, but what you're describing as common sense is actually describing some of the flaws with bitcoin.  It's a fantastic system, but if we work at it we can help make it idiot proof.

I'm still fixated on the crux of the issue: in that once a thief knows your private key the coins can be instantly transferred to any other address with no chargeback.  This is a fundamental feature of the bitcoin protocol itself, a great strength but also a huge weakness.  Surely isn't there a way to tweak the protocol?  I'm going to try to use a very simple example:

A.) Normally the private key that is paired with an address represents the way to transfer the value. Knowing the key gives a user the power to spend/steal the coins there instantly.  These can be thought of as "fast" coins.  Even if coins are in cold storage, knowing their private key makes them instantly spendable on the network.  So the private key is currently the weak point.  It must be hidden to all but the owner.

B.) But what if the system were capable of creating a new address with a different kind of private key by command.  One that would still be recognized as a valid, but this key has a different property that sets it apart.  Maybe it has an extra character, or a specific sequence of characters within it, just something that makes it so that the protocol knows its different and categorically "handles" it differently.  

C.) The protocol sees these coins with a different private key and knows that it will be subjected to a different set of instructions.  What instructions could those be?  Go crazy with ideas, but it might allow for some pretty powerful security features to be put into place.  So much so that you could feel comfortable sharing the private key itself.  The coins at that address could be sent as normal but they may have extra constraints on their behavior that any wallet client would recognize.  I.e. a time delay, a maximum per time period limit, a committed and locked forwarding address etc. These might be thought of as "slow" coins that have been temporarily been made to have these different properties as long as they reside at this address.  Sending them to a new address without instructions to modify the private key to be "different" again would revert them to their normal "fast" state.

Please understand I'm not talking about just changing the behavior of a wallet here, but changing the behavior of all wallets and a bit of the protocol itself.  I understand this is weird and foreign to many people who have worked with bitcoin for a long time, but this is coming from a deep desire to help further bitcoin and prevent theft.  

What it would look like in practice? Say Bob has 20 BTC that he just received.  He wants to further protect his BTC so he instructs his wallet client to generate an address that will have a modified private key.  The address is valid and anyone can send BTC to it, but it might even look a little different when shown.  Once coins are at this address, the blockchain knows to process them differently according to his input when he created it.  In bob's case, he generates an address that will cause the coins here to be locked up in pending for at least 72 confirmations before they are actually sent to an outbound address.  He sends the coins to this new address and they remain there.   The next day he pays a friend 2 BTC.  The blockchain processes this transaction and for the next 72 confirmations the blockchain does not actually send the coins, they are still within Bob's wallet at his modified address.  This is NOT a chargeback, it's priming to send.  Once the coins are sent Bob cannot get them back as usual in bitcoin.  About 12 hours later Bob's friend Alice notification that the coins are now in her wallet.  Since Alice is using a normal address, the coins behave as normal "fast" BTC, they can be spent instantaneously and have none of the properties that Bob gave them.  That night when Bob sleeps, someone who infected Bob's computer with malware attempts to import the modified private key from bob's wallet.  They're trying to steal all his remaining 18 BTC.  They copied it when his wallet was briefly unencrypted during his transaction with Alice. Bob wakes up the next morning and sees a notification that the coins sitting at that address have a pending withdrawal request that he did not authorize.  He cancels it, and the blockchain never sends it to the thief's address. Now in possession of his coins and aware that his computer is compromised, Bob takes the necessary steps to protect his investments.  This is a hypothetical case where the bitcoin protocol and wallets have been modified slightly so that even though a thief knew Bob's modified private key, the blockchain knew to process the BTC according to Bob's input at the time the address was created, and the thief could not steal it.

TL;DR - Currently, Private keys are not safe.  We should work to allow users to create safer, craftier, modified private keys

Also, I am aware that there is some complexity here I do not understand, such as multiple valid private keys per address for instance.  I wonder how this would affect it.

[wumpus]

You should be careful about the amount of BTCs you store on any online device. The specific client is least of your worries. Wallet encryption helps a bit, but if your PC or phone is really compromised it won't stop a determined attacker, certainly not one with root privileges (and direct memory access), from stealing them while you send coins.

There is no way that software can protect against such attacks.

If you have a large stash of BTCs please use an offline or paper wallet. And backup it very carefully. And there's companies working on hardware wallets, that would be an interesting space to watch too.

[Jobe7]

Dear OP,

You can already make hardware wallets, or you can (and should) store the majority of your wealth (Bitcoins) in cold storage, on multiple devices. If you're not sure on how to do either you can pm me or google it.

The only absolute way I can think of to address what you're saying is to have a 3rd Party hold your wallet (an escrow of some kind) and require you to provide your password and whatever other ID requirements you've set for them to require before they spend your funds on whatever item/person you wanted.

But then thats defeating the purpose of 'be your own bank', but let's be honest, there's definitely going to be people out there who don't trust themselves with all their wealth and would prefer a 3rd person holding a chunk of their wealth for certain spending procedures.

There you go OP, business venture idea right there, "a trusted 3rd party for when those encrypted wallets just don't feel safe enough!". The 3rd party would be faced with similar issues, but maybe they'd sign a clause with the person. And there we go, the start of a purely online Bitcoin bank It's gonna happen or later, I betcha.

[grue]

I can't even respond to Grue because he's just one of those guys that tells you that "you don't know anything."  Not helpful.

is your attention span 10 seconds? because I responded to every single suggestion you made. all you're doing is making vague suggestions with no way to implement with the current protocol. for example, the "delayed addresses" suggestion. how exactly is that going to be enforced? even if it could, how would it help if your computer was infected? the attacker can simply wait a few days until the funds are available.

come to think of it, what's wrong with the systems currently available? we have multisig transactions, as well as printable cold wallets.

you're the one making the suggestions. half baked ideas are dime a dozen, what we need are ideas with implementation details.

[coastermonger]

is your attention span 10 seconds? because I responded to every single suggestion you made.

Your responses were: "how?, impossible, impossible, and lol." I'm sorry if you actually meant to inspire some discussion, I must have taken it  the wrong way.  It's fine, I'm going to refrain from ad hominem here and assume you didn't read the entirety of this response: https://bitcointalk.org/index.php?topic=209409.msg2198370#msg2198370 (as it really was too long)

I'll take pretty much everything I said in that reply and condense it down to a few lines:

• Private keys currently represent a problem in that once they are shown the BTC can be stolen immediately, to anywhere.
• But what if we could sometimes create addresses for ourselves that purposefully had a certain kind of private key.
• Imagine if the protocol itself were tweaked to recognize certain private keys as different.  (crazy simple example: any private key starting with "E9" has property X)
• It means any coins at that address will be handled differently by the blockchain itself, a universal property that everyone has agreed on.
• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.      
• In effect a malware program could view a private key, attempt to steal the coins, but the blockchain would handle those coins differently coming from that address and the user would get the option to cancel the pending transaction before it is actually stolen.
• What properties the coins have depend on how the the bitcoin protocol is coded to handle the modified private keys.  We could imagine any kind of behavior changes for extra security or functionality.  Once a key is made, it makes actually changing the entire protocol to necessary to change how those coins behave.  Once the coins are spent from that address, they no longer have that behavior.  It is truly a temporary, user-initiated property.
  

[DannyHamilton]

• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.       

This would not be possible.  The blockchain and all the peers never get to know what your private key is.  That's why the key is called a "private" key.  It isn't visible to the blockchain. I suspect that what you are looking for is a new transaction output script.  It is the output scripts of the transaction that determine what the requirements are for later spending that output.  The reason that the vast majority of transactions can be spent with a signature from a private key is because the output script when the bitcoin was received specified that the only thing required was a signature from a private key.  If you want a different spending requirement, then you have to convince the person sending you the bitcoins not to simply send to a bitcoin address and instead to use an output script that adds additional spending requirements.  Here are the script programming commands that can be used in an output script.  If you can come up with a good solution from this set of commands, perhaps you can convince others to use a wallet/client that supports your new script requirements:

https://en.bitcoin.it/wiki/Script

If there is a particular command that is missing from the set, perhaps you can get a client created that supports additional commands.

[aaaxn]

is your attention span 10 seconds? because I responded to every single suggestion you made.

Your responses were: "how?, impossible, impossible, and lol." I'm sorry if you actually meant to inspire some discussion, I must have taken it  the wrong way.  It's fine, I'm going to refrain from ad hominem here and assume you didn't read the entirety of this response: https://bitcointalk.org/index.php?topic=209409.msg2198370#msg2198370 (as it really was too long)

I'll take pretty much everything I said in that reply and condense it down to a few lines:

• Private keys currently represent a problem in that once they are shown the BTC can be stolen immediately, to anywhere.
• But what we could sometimes create addresses for ourselves that purposefully had a certain kind of private key.
• Imagine if the protocol itself were tweaked to recognize certain private keys as different.  (crazy simple example: any private key starting with "E9" has property X)
• It means any coins at that address will be handled differently by the blockchain itself, a universal property that everyone has agreed on.
• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.      
• In effect a malware program could view a private key, attempt to steal the coins, but the blockchain would handle those coins differently coming from that address and the user would get the option to cancel the pending transaction before it is actually stolen.
• What properties the coins have depend on how the the bitcoin protocol is coded to handle the modified private keys.  We could imagine any kind of behavior changes for extra security or functionality.  Once a key is made, it makes actually changing the entire protocol to necessary to change how those coins behave.  Once the coins are spent from that address, they no longer have that behavior.  It is truly a temporary, user-initiated property.
  

It all can be easily done when we replace output/input script with account ledger, which just keep an balance attached to an address. With this design you could easily make account type which has withdraw limit defined or which has two keys. One limited and one allowed to spent without limit. It would also fix many other problems of bitcoin(eg. dust output, ever growing blockchain, ...)
Some ideas can be found here:
https://bitcointalk.org/index.php?topic=195275.40

I don't think you will find support for your ideas in bitcoin supporters. Everybody seems to be in love with current bitcoin design no matter how complicated and inefficient it is.

[wumpus]

I don't think you will find support for your ideas in bitcoin supporters. Everybody seems to be in love with current bitcoin design no matter how complicated and inefficient it is.

It's certainly interesting, but it's more the domain of altcoins than bitcoin. I wonder why all the current altcoins are literal copies of bitcoin, and no one is experimenting with more wildly different ideas like that.

[coastermonger]

To DannyHamilton: I appreciate your insight and for bringing up the topic of output scripts.  You seem like a really knowledgeable guy.  I am sorry that my terminology might not be up to par.  So the blockchain itself does not see or store private keys, got it.  But the wallet does correct?  What I am trying to do is introduce the idea that sometimes the private keys themselves could be generated to have some specific function like an output script.  It would have to be a universal quality that any wallet would recognize.  What would technically need to happen to make this change?  Be as grandiose as you like, it's just brainstorming.

To aaaxn: I'm curious about your idea of replacing input/output script with account ledger.  One of the main problems I'm trying to solve is that sharing a private key always allows instantaneous theft/transfer of a coins.  I want to give users the options to sometimes not make this the case, to be able to store their coins in addresses that have private keys which modify the behavior of how their coins can be spent.    (the protocol itself would have to be modified to accomodate this behavior) Under your example, could I still immediately steal all of your coins if I discovered the private key of your address?  Why or why not?  I'll also make sure to check out the other idea thread.

And to John Smith: I realize that this might be more the domain of alt coins if the changes to bitcoin are too complicated or too far gone to implement.  I just kind of hate the idea of introducing another alt coin.  I'm ultimately curious if these are changes that can be introduced because they would keep the current functionality of the bitcoin protocol intact, but also change it for those who want the option to.

[wumpus]

And to John Smith: I realize that this might be more the domain of alt coins if the changes to bitcoin are too complicated or too far gone to implement.  I just kind of hate the idea of introducing another alt coin.  I'm ultimately curious if these are changes that can be introduced because they would keep the current functionality of the bitcoin protocol intact, but also change it for those who want the option to.

The way to do it would be to first experiment with it on an alt chain. Once it turns out to be workable, and the alleged advantages really hold up, it could be implemented in Bitcoin. In principle it's possible to change a lot of the internal workings using a hardfork (see also https://en.bitcoin.it/wiki/Hardfork_Wishlist) but it has to be proven first.

[skull88]

Not a programmer, nor a security specialist but isn't it possible to build in the client something that allows you to besides encrypting the wallet with a password you can also encrypt it with something like a yubikey, so that you actually need something physical to decrypt it? So if a computer is infected they still can't send any coins because you also need the usb device.

OP has a point, I have the knowledge to keep my coins secure. But no way my mother could do this, sticking something like a usb key in the computer is even for her a nobrainer.