Quote from: blackarrow on September 28, 2014, 03:26:39 AM

Dear Bitcoin Developers,

We would like to propose a feature in Bitcoin protocol in order to reduce the number of Bitcoin thefts.

Real world scenario: attacker installs a trojan into your computer, downloads the Bitcoin wallet and keylogs your computer to get the password. The attacker can and will spend all your money and there's nothing you can do about it.

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

   This will function in the same way as a safe does: The owner of the address will announce the network that he/she wishes to lock this address and will require X amount of minutes/days to be unlocked.
   This would mean that the Bitcoin network will require the user to issue the unlock command and wait for the timer to expire before allowing him/her to spend the money from that address. The GUI client must announce the owner that his address has been unlocked and display a countdown timer so he has a chance to take action.

   There's a problem with the above scenario: as the hacker has access to the keys, the owner still cannot stop spending because he/she can lock the money again but the attacker can unlock them, triggering a race that leads only to a draw (permanent lock of the funds) or the attacker to win (as the hackers are dedicated to make software that will trigger their transaction faster or will spend higher commissions to get the transaction processed quicker etc).

Here is the solution to this problem:

   Lock command will also require an emergency backup address. A 2nd lock command issued will not allow to change the emergency backup address. If the attacker triggers the unlock command and the real owner wants the money back, he/she can issue an emergency recover command and the network will send the money to the emergency address (that was set-up when the first lock command was issued). It is important that transfer will be completed only after the lock timeout expires and the new address will be locked again for the original timeout. This is required in order to give a chance to the real owner to issue the last and final command (if the hacker had managed to get access to the 2nd address as well).
   The last and final command that can be issued by the real owner of the new address will be to destroy the funds. The funds will be destroyed, not sent to the miners. This is important in order to deter the hackers to develop any other techniques to steal the money (for example few days ago I read that they hacked 6 ISPs and redirected the whole hashing power towards themselves). If we do not destroy the funds, we are inviting them to hack our hashing power.

To summarize:

lock(address, delay, emergency address)
note: a new lock command, issued while the lock is active, will not accept to change the emergency address or the delay.
unlock(address, where_to_spend);
note: a new unlock command will refresh the timer to the original lock command. If a previous unlock command was issued with no address to spend, there will not be accepted any new addresses
issue_emergency(address);
will cancel any unlock commands and send the money to the emergency address set with original lock(). emergency address will be locked for the same amount of time as issued by original lock(). No further unlock commands are accepted.
destroy(emergency_address);
can be issued only on emergency addresses that are locked. it is important that this transaction to be signed by emergency_address only as we do not want the hacker that has access to our original address to be able to destroy our saved funds.

Regards!

Instead, why don't you propose a system where after you manufacture bitcoin mining hardware with customer preorder money, you deliver it to your customers in the advertised time period, with the advertised compensation plans, with the advertised quality.

Even better, when customers ask why their orders have yet to be manufactured even 6 months after your revised ship date, you tell them the truth and explain the current compensation plans instead of worrying about your untouched bitcoin hoard and funding the next 14nm preorder scam.