Meh. All this sub-currency stuff is a complete distraction, I think. How about a pair of new script opcodes:
One signifies an intent transaction which declares an intent to spend particular inputs to particular outputs (and has its own inputs and outputs, but only for the purpose of fees and change).
The other specifies that the output of the txn containing it can only be spent if combined as an input with a matching intent transaction from N blocks prior. The intent output this transaction must be to the same address(s) as the source transaction so the intent transaction can be effectively replaced by the holder of that key by simply transmitting a new intent transaction that redeems the prior one.
OK. Sounds good. I don't care about the details of how it's implemented for now. Just about the functionality and that it is in principle doable.
Of course, this doesn't really work
for three reasons:
One you noticed:
The only problem I see here, is what happens if your safecoin private key is compromised. The thief tries to withdraw all your moolah, but you (or more accurately your bitcoin client which runs 24/7) sees this attempt and cancels the transaction.
There is no way to end the race. If you had a "Safe haven" address that you can trust the attacker doesn't have access to, then you should simply multisig escrow the transaction with that address in the first place and avoid all this stuff.
Firstly even if there was no way to end the race, this would still be beter than what we have now. Secondly, if your script opcodes can support definition of safe haven addresses, the outcome is vastly better. I don't believe the multisig escrow solution is equivalent. The key reason for this is to recognise that every time you USE a private key, you are placing it at risk, because in order for you to use it you will have to decrypt it and have it in plaintext form in memory on some machine that may well be compromised. If the second signature is generated on a different machine than the first, it becomes safer since both machines would have to be compromised before your funds are at risk, but this severely impacts useability for everyday transactions.
With the safe haven address solution, the second private key is typically never used. It may be lying in an encrypted wallet somewhere on a USB stick in a safe location or on a server in the cloud. It contains no money and it never gets decrypted. ONLY if your primary account is allready compromised do you access this information and in this situation you don't care so much that it is a hassle to format a new HD and start with a known clean system (or pay a trusted party to handle it for you securely) since you don't have to do it every time you want to tip someone 0.01 BTC.
The second is if the attacker works with miners she can arrange so that the miners mysteriously doesn't manage to hear any of your retractions before it is too late, and the miners can plausibly deny their role in the attack. They can even learn to do this automatically without prior coordination with the attacker by looking for intent transactions which indicate intent to outputs with large fees.
Fair enough, but if you are going to invoke corrupt miners, then ALL transactions are at risk of chargeback. I happen to believe that this is a serious issue as discussed here http://forum.bitcoin.org/index.php?topic=20171.0
, but if anything it is less applicable to intent transactions than to normal transactions since even a small fraction of honest miners will get your intent tx into the chain with high probability if N is large enough. Of course corrupt miners could then invalidate that block if they control more than 50% of network power, but in that unlikely case chargebacks will abound and bitcoin will be abandoned en masse by retailers anyway.
The third is that if the attacker has compromised your machine in order to obtain your wallet in the first place they will simply make your machine either not see their intent and spend, they will disable the functionality, or they will gobble up the attempted race messages. They can even do this without actually having the machine itself currently compromised if they are able to gain enough control over the network connectivity: Nothing in bitcoin today makes control of the network seriously worse than a DOS attack, but in this situation control of the network would completely moot the reversal war. They could also simply DDOS nodes emitting the reversal TXN off the internet.
For that reason it may be best to use a webservice to issue the reversal txn. This service could use a distributed network of nodes all watching the blockchain and issueing a reversal tx if an intent tx is issued for one of the wallets they are guarding without having received an unlock first via a secondary channel. Unless they are all DDOSed (BEFORE they get the chance to tx the reversal, implying that the attacker knows their IPs beforehand) the reversal will go through.