This is a very powerful argument. The problem is that many people may not even realise they are stealing. A single corrupt individual releases a new android app that attempts a double spend 2 minutes after every transaction. This spend targets 50% of the value at miners 25% to the author and 25% back to the originator. This gets pitched as a "loyalty program" where you would occasionally win 25% cashback on transactions. Initially people don't even know they are stealing, so this gets real popular real quick.. Then retailers make a noise and most people know, but suddenly it looks more like a morally gray area.

Also most people won't steal from a mom & pop shop after looking the shopkeeper in the eye. But many have far less of a problem ripping off Wallmart or pretty much any giant faceless corporation. How many people point it out when they are given too much change at a till?
 

Problem is, if many people are doing it, the total bribe quickly adds up. If it works, more people start doing it, more miners become corruptible and the vicious cycle fuels itself. Even a 0.01 BTC bribe may be enough if the block was going to get invalidated anyway due to other unrelated bribes.

Agreed.

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.  

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.

You're right. I was being  dufus. 

Fair enough didn't mean to imply that they would have to understand all the nuts and bolts. If that was the case very few people could use BTC. I know I couldn't. But the steps that they need to follow TODAY are too complex. Widespread adoption of smartcards and smartcard readers on consumer devices may well change that. But even then, physical theft of your smartcard combined with a keylogger or just someone watching you enter your password would place at risk ALL of your bitcoins. ATM cards get stolen and PINs compromised every day, but at least the damage is limited.


No I don't. But to refill my wallet when I've spent my $100 is a simple process. I go to an ATM and I withdraw. As long as I don't need a large amount the process is hassle free. And IF something goes wrong and my PIN is compromised I only lose a small amount.

Refilling my "mobile phone account" from my "secure account" using the webservice you outlined here is a royal PITA, even if I only want 1 BTC. What's worse is that I could still lose all my BTC if there was a trojan lurking on my PC just waiting for my investment account's private key to be loaded into memory in plaintext form (as it ultimately needs to be if I am to sign transactions using it). The solution is not JUST keeping the keys to the kingdom in stronger and stronger vaults, but to limit the damage that can be done if (when) these keys are compromised.

You won't be able to do it with scripting even if you could take amounts into account, because the script for this transaction would have to affect all FUTURE transactions from this wallet. This is fundamentally diferent from what scripts do today. You may be right that it is too big a change to introduce at this point. On the other hand, you have to consider how common things like the allinvain heist would become if bitcoins became mainstream. Unless wallet security is simplified vastly simplified, the VAST majority of users will be insecure. Suggestions for USB drives in safes and wallets printed to paper abound on these forums. My sister won't ever do that, not to mention my parents or grandparents.

A couple more such heists could well kill the possibility that Bitcoin (or any other cryptocurrency) could ever go mainstream. The only reason why anyone uses credit cards online is because credit card companies have proven to absorb (or offload to merchants) a lot of fraudulent transactions. The client is rarely left to take the loss when CC details are compromised. People don't need a reason to distrust computers. It comes naturally to most.


I like this a lot. It may well be the best we can do. Certainly a lot simpler than a live distro with a wallet on a USB key in a safe. But it's a pity that we lose the ability to do small transactions without hassle.

Anyone else? Or is this not even worth shooting down?

But this does make one doubt the oft-repeated statement that a retailer does not need to wait for confirmations when selling goods of small value. I could buy a cup of coffee and broadcast a new version of the transaction into the network offering half of the price as tx fee. If 10% of miners are maximising transaction fees then there's a 10% chance I get a 50% discount on my coffee. If everyone does this the retailer sees a 10% loss. Suddenly makes Mastercard and VISA look good.

As far as confirmed transactions are concerned, one can easily calculate for a miner with a give percentage of total network hash power that coldly maximises profit, how large the tx fee would have to be to attempt to overturn something X blocks back in the chain (assuming that none of the other miners are bribeable and he needs to do it alone). The figures look good for solo mining, but for pooled mining and especially 0% fee pooled mining, the situation quickly changes since the pool owner (who will make the decision) will keep all of the bribe if he attempts the heist and is successful, but keep 0% (or a very small %) of the coinbase reward if he chooses to keep to the straight and narrow.

Once miners know that other miners may be corruptible the figures change dramatically and a vicious cycle may be born. Also, a large bribe on large tx is not necessarily required, many small bribes on many small txs can add up to the same effect. All in all, I'm a little worried. Please tell me why this won't happen.

please let me out. only made 1 post here, but I don't want to post for posting's sake and there's a thread in the development section I really want to go comment on.

Regards
H

I'd ideally like to post this in the Development and technical discussion board, maybe a mod can move it there. Been frequenting the forum a couple of months now, but am more of a lurker than a poster. In this instance, however, I believe I have something worthwhile to contribute.

After the allinvain heist and the confirmation of the existence of a bitcoin stealing trojan, the boards have been awash with suggestions for securing bitcoin wallets, and while most of these will undeniably make it far harder, or even impossible, for a thief to steal significant amounts of bitcoin from a properly secured wallet, securing a large amount of BTC needs to be far easier to make it accessible to the general public.

What I would like to propose is an additional transaction type that would allow you to specify constraints on the use of funds from a specific address. This is analogous to the existence of cash withdrawal limits on an ATM card that the bank customer may configure. The CREATECONSTRAINT transaction would not move cash between adresses like normal transactions but would list a source adress (to which the constraints would apply, a MAXMOVE amount and a list of N safe haven adresses.

Once the constraint transaction has been incorporated into the blockchain, the network would disallow any subsequent transactions that attempt to move more than MAXMOVE bitcoins to any adress not in the list of safe haven adresses. This would be enforced on a per block basis, in other words nodes have to ensure that the total amount of bitcoins moved from the source adress in a specific block does not exceed MAXMOVE. If multiple transactions using that source address are received, any transactions targeting safe haven adresses will be prioritised, and all others would be added in, in the order received up to the point where adding the next transaction would violate the constraint.

In practice this would mean that I could safely keep thousands of bitcoins in a single address in a wallet, configure the address to not allow transactions of more than X BTC per block (where X is a reasonable number for everyday expenses) unless the receiver is one of a small list of alternate adressess that I control. Obviously this helps nothing if the private keys for the safe haven addresses reside on the same machine as that of the primary address, but these could be addresses that reside on my mobile, addresses of trusted friends or even a mybitcoin or mtg*x deposit address. I could also keep them on a USB stick with a live distro, but I probably don't need to keep the stick in a safe, since the adresses are usually empty.

If my primary address is compromised I can request the movement of my funds to one of the safe haven addresses and only lose a relatively small amount depending on how quickly I reacted. I can also do the same thing if the address is not compromised but I need to do a transaction larger than MAXMOVE.

Of course safe haven addresses are also adresses and as such could have their own constraints. The uber paranoid could create complex networks of wallets that need to be traversed before the money reaches an unconstrained address. Unless the attacker manages to compromise ALL the wallets in the chain, he will only be able to siphon money off very gradually (or not at all if MAXMOVE=0). Similar things could be achieved with multi-signature transactions, but this method has the advantage that small value transactions remain as simple as they are today even when sourcing funds from high value wallets.

A CREATECONSTRAINT transcation is checked for validity by ensuring that if any CREATECONSTRAINT transaction for this address allready exists, then the new transaction may only tighten the constraints (i.e. reduce MAXMOVE, specify a subset of previously listed safe havens) and never relax them. One could also consider having some default MAXMOVE amount defined for all adresses. The first CREATECONSTRAINT transaction that gets processed for a given address would be allowed to increase MAXMOVE from this default level.

This doesn't help if your wallet is compromised and you only realise it 10000 blocks later, but it would be simple for third parties to build payment notification services that would send you an SMS/e-mail every time BTCs are sent from one of your addresses.

If the extra kBs consumed in the blockchain are an issue one could always prevent gratuitous use of the CREATECONSTRAINT transaction by requiring a non-trivial transaction fee.

Comments?