|
June 17, 2011, 05:57:58 PM Last edit: June 17, 2011, 07:55:06 PM by xanatos |
|
I would suggest a feature. It would break a little BTC, but not very much.
When you make a transaction you can mark as "Parked" or something similar. It means that any transaction that is based on that transaction is reversible in n time (where n is fixed when you create the originating transaction) (we could say that any transaction outgoing from that transaction is slow to start). This attribute is public, so anyone can see it.
The use (and an example): let's say I have 25.000 bitcoins and I want to protect them, but I still want to be able to spend them. I know that simply saving them on an external disk is useless, because an opportunistic virus could wait and steal this secondary wallet. I send them to myself marking them with "park, 1440 blocks (10 days give or take, right?)". We call this the transaction A. Now any transaction B that is based directly from transaction A is reversible in 1440 blocks from the creation of B and won't become confirmed before 10 days pass and so I can cancel it (I know a feature to cancel an unconfirmed transaction is already in the work). There are two scenarios from here:
A) I need the money: I will have to transfer it to a "standard" transaction waiting 10 days. Then it becomes again "standard" BTC. (in fact only transactions directly connected to transaction A have to wait) B) Someone steals my money: he can try to spend them, but I can cancel its spending if I notice it in 10 days (we could make the client remark that a "Parked" transaction has been "activated"). Technically me and the thief could begin cancelling each other the transactions based on the transaction A and the money would get in a limbo... But it's probable that the thief would lose interest... More times it tries to cancel the transaction more risks he has. And in the end it's better "lost" than "stolen".
As an add-on, on this "special" transaction we could save a "master password" (a signature with a different public-private key, protected on the wallet.dat by a different password than the "standard" password that will protect the everyday keys), so anyone that has the master password can activate the transaction without waiting the time, but I'm not sure this would be a good idea (we would return to the original problem)
Ok... My english isn't very good... Please someone can make it comprehensible?
|