Post
Topic
Board Development & Technical Discussion
Re: Wikileaks fixed spend time retractability suggestion
by
gmaxwell
on 22/06/2011, 21:56:30 UTC
Wikileaks recently tweeted a reply (http://www.twitlonger.com/show/b8qli4) to a news article spreading FUD about Bitcoin.  In it they suggested Bitcoin "be augmented with a sub currency that has fixed time spend retractability if it is to be successful as a safe storage (as well as exchange) currency for the average person".
I was thinking the purposes of this could be accomplished by the client putting a fixed time delay on sends.  Of course, the user could always have the option to force transactions immediately.
If the recipient needs proof that the sender indeed has the necessary funds to send in the meantime, a message could be signed using the private key associated with an address containing them.
This would also provide some protection against "fat finger trades".
Am I understanding their concerns correctly?  Does this address them, effectively?
Edit: I guess part of their concern is theft.  Hopefully this can just be sufficiently mitigated by better security features in the client.

Right, their concern is theft, so a voluntary delay is pointless— otherwise I would point out that you can already form post-dated transaction in the bitcoin protocol by using the nLocktime field.  (Can't be mined until a particular block number or network time).

I think its a mostly a nonsense concern, and actually insoluble the way they suggest. People already suggest that the confirmation time in bitcoin will cause the system to fail, so adding a mandatory additional time to confirmation would _not_ help.

As far as it being nonsense— no cashlike system has this feature and they work fine. As you suggest the solution to theft in the context of cash is better security.  Transferring your savings into a offline wallet (a piece of paper or usb key) is analogous to locking your cash/gold bars in a safe and is the reasonable and prudent thing to do.

If bitcoin continues to grow in success I expect we'll also see secure hardware wallets— special devices that hold your keys securely and which you plug in via USB to send and receive from.

There are, however, technical things we can do to improve the security beyond just the basic "secure your computer/wallet".

For example, the user could transfer the funds into in-blockchain-escrow by forming a transaction that two signatures (the user's and a third parties) that are required for release of the funds.  Offering the service of being a third party signer for such transactions (perhaps requiring additional authentication or a time delay for release) may eventually be a reasonably profitable bitcoin business.

Another thing we could do is write code for miners that allows you to _bump_ a pending transaction out of their queue prior to it being mined if a conflicting transaction comes in that has a sufficient fee (Perhaps 1 BTC + 3% of the value).  A mode could be offered in the bitcoin client where if it sees someone else spending its coin it generates a fresh and safe keypair then produces a conflicting txn with the appropriate fees which locks the funds under a new key plus a preselected escrow service key, and this transaction hopefully gets mined first. This couldn't be a default because people using the same wallet from multiple places would shoot themselves in the head with it.

This would increase the risk of accepting unconfirmed transactions, because it provides a ready reversal mechanism for unconfirmed transactions to everyone. So as a community we ought to think long and hard about it before allowing it, but it's a possible option which doesn't require any kind of grand redesign or slow down transactions further in the common case.

Of course, there will be other ways to work with bitcoins in the future — e.g. bitcoin backed debit cards that provide centralized confirmation for very fast and low value transactions. But I don't think that additional currencies (be they distributed or centralized) are at all appropriate for addressing the security concerns.