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?