Topic: Wikileaks fixed spend time retractability suggestion (Read 1154 times)

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.
 

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.  


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.


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.  

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.

Of course, this doesn't really work for three reasons:

One you noticed:


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.

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.

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.

Namecoin uses a kind of intent traction to lock names so that people watching the txn flow can't claimjump you, it's quite nice. Unfortunately enabling claim jumping is an entirely different matter than preventing it.

I actually think that is quite a good suggestion. It's important to realise that no-one is suggesting that bitcoin transactions be made slower. The suggestion was for a sub-currency that has slower confirmation. Let's call it safecoin to make the following discussion easier. This could be as simple as a special address format that is accepted within the bitcoinchain (e.g. all even bitcoin addresses are automatically treated as safecoin adressess). This means that half of all bitcoin wallets would now be treated as safecoin wallets. Since one can transfer between bitcoin and safecoin wallets, and since mining is unaffected, bitcoins and safecoins are pegged at 1:1 and the supply is still limited to 21 million.

If you didn't want your pre-existing address to suddenly become a safecoin address, no problem, just transfer the coins to a bitcoin address. At worst you have to wait a few hours. Then, in future, payments from safecoin addresses will only become final once a set number of blocks has passed without a retraction tx being issued. No-one would accept payment in safecoins, but that is not a problem. Simply transfer the amount you are planning to spend in the next week or so to your bitcoin wallet from time to time. In this context it is perfectly safe since you are transferring money to yourself and trust is not an issue. Once the money is in the bitcoin wallet it becomes liquid, but also become at risk.

Perhaps this should not be referred to as safecoins or as a sub-currency, since they are still bitcoins, but there are just two different classes of bitcoins with a different liquidity/security tradeoff. Similar to the difference between $1M in a savings account and $1M in cash. They are worth exactly the same. The risks of holding $1M in cash are greater since if it's taken, it's gone, but this is compensated for by the fact that anyone will accept payment in cash with no delay, while there will be an inevitable delay if you are transferring large sums of money from your bank account.

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. Now you try to move your stash to new safe address, but the thief sees the attempt and issues another revoke. Worst case, this continues indefinately and no-one gets the money. This is better than where the thief gets the money but not all that great if you're still out 10000 BTC. This could be solved by defining one or more safe-haven addresses (similar to what I proposed here http://forum.bitcoin.org/index.php?topic=20753.0) but this requires more extensive modifications to the protocol.

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.

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.