[Idea] Could we build a service to counter wallet theft?

[hacknoid]

OK, I have been thinking about this for a while now and I wanted to bounce some ideas off the community.  Note that with the recent headlines about all the bitcoin wallet stealing malware, I think a service such as what I describe here could really help Bitcoin's reputation.  Any and all criticism, suggestions and comments are welcome.  

Summary
A user would register transactions with the proposed service that would move coins from one wallet to another (safe) wallet.  In the event that the service notices an attempt to empty the contents of the wallet, the saved transaction would be broadcast in an attempt to move the coins to safety before the wallet could be emptied.

Overview
Bitcoin wallet thefts have occurred since for several years now.  There are many ways this can happen (non-password protected wallet stolen, wallet backup stolen, keylogger for password or web wallet, intercepted email wallet backup, etc.) but the common thing in each case is that the attacker gains control of the wallet then transfers the contents to another wallet under their control.

Interception
Given the nature of the way bitcoin works, the transfer to empty the wallet is broadcast and is (almost) immediately visible to the entire world.  Thus a service that is watching for suspicious transactions from a wallet could see this right away - even before it gets included in a block.

Solution?
What I am thinking is this.  If someone was wanting to safeguard a wallet, they could create a transaction that sent the contents (or some amount) of the wallet to another wallet under their control - a safe, secondary wallet.  BUT, this transaction would not be broadcast - it would be an "emergency eject" transaction.  As far as I am aware, it is possible to create transactions but not broadcast them right away.  My thought is that the user could upload the transaction to the service I am proposing, which would then watch for a "trigger condition" (generally, emptying the wallet).  At that point the service would broadcast the eject transaction and effectively initiate a double-spend race attack.  While generally frowned upon this would be a case that could potentially save a user from a stolen wallet.

NOTE: doing this means the service does not require access to the wallet itself nor the private keys. It would only need to know the wallet address, trigger condition and eject transaction.

Factors
Now, there would be probably at most a few seconds between notice of the wallet emptying and the broadcast of the "emergency eject" transaction.   If the service was well connected, it could potentially gets its transaction picked up by more nodes first.  Ideally any options that would help to get the “eject” transaction confirmed would be good:
- higher transaction fee than the hackers?
- preferred confirmation of the “eject” transaction by miners?


Drawbacks
PROBLEM:  the hacker could use the service to ensure emptying of the wallet by registering itself with the service with a new wallet destination.  
MITIGATION: service would not accept a secondary request for a different wallet.

PROBLEM: no guarantee that the emergency eject will work (see Factors).  
MITIGATION: get buy in from miners/pools to accept transactions broadcast by the service over other ones.

PROBLEM: could be used by people to perform a real double spend attempt by simply registering a wallet with the service before attempting to do a real spend.  
MITIGATION: provide api to query if wallet is being guarded and or if the requested transaction would succeed.  Note (although I am loathe to make this comparison) this would now become akin to the the credit card automated confirmation service that merchants use at a POS terminal.  However, all this would do is confirm that this particular service does not have a watch trigger on this wallet, and/or that it would actually fire.

PROBLEM: a legitimate transaction from the wallet could trigger the eject transaction to be broadcast.  
MITIGATION: the user would need to register an account with the service.  By logging in to the account and effectively whitelisting a transaction that would otherwise trigger the condition, the eject transaction could be (temporarily) offset.

PROBLEM: The eject transaction may try to transfer more coins than are in the balance of the wallet if not looked after (i.e., on an active wallet).   Thus the eject transaction would fail.  MITIGATION: Register multiple eject transaction with varying amounts of coins, leaving the service to decide which one(s) to broadcast to move the maximum contents of the wallet to safety.  (NOTE: if the transaction fee amount is a factor in which transaction gets confirmed, different transaction with varying transaction fees could also be registered).

Questions
These are the parts I am not too sure about:
- Is there any way to make a transaction that sends the entire contents of the wallet, rather than a fixed coin amount?  
- If a miner sees two transactions that cause a double-spend, does it always only include the one with the earlier timestamp?  If so, then maybe this is a non-starter (other than trying to ensure the service is better connected in the network)
- If the "emergency eject" has a higher fee would it have a better chance of getting included in the block even it was later?
- Can these transactions be created on a wallet without rendering the contents otherwise unspendable by the rightful owner?
- Is it possible to know that the transaction was broadcast by the service?  If so, then with the acceptance by the mining community to prefer the “eject” transactions, the service becomes much more valuable and effective..


**EDIT**: One other function that a service like this would serve to help with is lost or forgotten key/wallets/passwords.  In the event that for some reason a wallet couldn't be accessed any longer by the user but an "eject" transaction had been created, it could be triggered to be broadcast if the wallet was not accessed for X days.  Then the contents could move somewhere else that could be accessed.  Of course you would have to be careful with cold storage wallets, but that goes without saying.  However, the wallet that winds up in a hard drive in a landfill or is set up by a person who dies would have contents that suddenly become able to be accessed again, all automatically.

Edit: I may want to work on this after all... Since I don't seem to be getting much comment on here and I do think it's important.

... comments?

[1714042209]

1714042209

[1714042209]

1714042209

[1714042209]

1714042209

[t3a]

Summary
A user would register transactions with the proposed service that would move coins from one wallet to another (safe) wallet.  In the event that the service notices an attempt to empty the contents of the wallet, the saved transaction would be broadcast in an attempt to move the coins to safety before the wallet could be emptied.

How do you define emptying the wallet? What if I have $500 and want to spend $200 of it? Also, a "saving" transaction might not work if the attacker pushed a higher fee tx to the miners. Even if they didn't push to the miners, if they broadcast a transaction stealing your entire wallet, then you would somehow have to make your "saving" transaction be put in a block instead of theirs which was broadcast first.

Questions
- Is there any way to make a transaction that sends the entire contents of the wallet, rather than a fixed coin amount?

Not unless you keep remaking the transaction.

- If a miner sees two transactions that cause a double-spend, does it always only include the one with the earlier timestamp?  If so, then maybe this is a non-starter (other than trying to ensure the service is better connected in the network)

The miner will do whatever his software choses to do. The smart thing for the miner is to include the higher fee tx. The network will not relay a double-spend though, so you need to push it directly to miners.

- If the "emergency eject" has a higher fee would it have a better chance of getting included in the block even it was later?

If it reaches the miners, yes.

- Is it possible to know that the transaction was broadcast by the service?  If so, then with the acceptance by the mining community to prefer the “eject” transactions, the service becomes much more valuable and effective.

You could send it directly to the miners, but most miners/pools go by monetary incentives and not ethics *cough* GHash *cough*.

[hacknoid]

How do you define emptying the wallet? What if I have $500 and want to spend $200 of it? Also, a "saving" transaction might not work if the attacker pushed a higher fee tx to the miners. Even if they didn't push to the miners, if they broadcast a transaction stealing your entire wallet, then you would somehow have to make your "saving" transaction be put in a block instead of theirs which was broadcast first.

The simplest definition of emptying would be to transfer the entire contents, as it is what usually happens.  However, if this began to be guarded against the attack would then likely come as several separate transactions to empty the wallet in pieces.  The service could offer the option of defining what emptying would be (anything greater than XX BTC in one transaction or over a certain period of time, perhaps). 

If you wanted to spend YY BTC and YY >= XX, then this is where the user would have to alert the service to whitelist the request, as described above.  If it YY < XX, then you could just spend the amount without requiring any further action.

If the fee on the saving transaction needed to be higher to succeed, then this is where the user would need to create several transactions, with varying fees in order to combat this.  Alternatively, the best solution would be if the miner would choose to accept a transaction broadcast by the service over another one, regardless of relative fees (a hacker could put 10 BTC in the transaction fee if that meant it would go through, while a user would never do that willingly for his own transaction).

- Is it possible to know that the transaction was broadcast by the service?  If so, then with the acceptance by the mining community to prefer the “eject” transactions, the service becomes much more valuable and effective.

You could send it directly to the miners, but most miners/pools go by monetary incentives and not ethics *cough* GHash *cough*.

If a service were implemented and were to become effective, this would increase the value of bitcoin, and thus the value for the miners.  So while an individual hacker transaction might make more sense to be accepted because it has a higher fee, the overall monetary gain would be most to help make a more reliable and safe system for everyone.  Of course, as you say, its up to the miners.

Thanks for your responses and input.