Topic: Doublespend Protection Insurance (Read 3722 times)

Maybe. It's just nice right now to have a good response to the argument - "Oh Bitcoin could never be used for retail, the transaction would take too long, or the retailer would risk getting stung by doublespends." This as a problem that is solved in theory.

Doublepspend insurance is not needed yet.  Either the item is too cheap and the attacker could get a larger reward by mining with his hardware, or the item is probably not going to be delivered before the doublespend is detected.

Maybe in the future someone will sell a database or software for BTC that is expensive, and deliver it too soon but I don't know of any serious attack possibility that would be financially worthwhile.

Influencing legislation doesn't have to be very expensive: incriminating someone with selling cp or terroristic equipment for Bitcoins will quickly get you the negative publicity needed to pave the way for passing a bill outlawing anonymous cryptocurrencies. With some connections to politics and media, this should not be too difficult.

You are right in that attacking the exchanges won't stop the network, but it could cripple Bitcoin nevertheless (price would plummet, hashrate and confidence would follow soon). It would be more or less the same scenario as if some major jurisdiction was to outlaw Bitcoin.

Having 2% of the network would be in excess of 100 Ghash currently see http://bitcoin.sipa.be/).  That kind of hardware will set you back by at least $50,000 (if not closer to $100k).  If you're talking about relatively small value transactions, you will need to pull off a lot of double spends to make it worthwhile.  I think if you employed counter measures once a double spend is successfully executed, you could easily undermine the economics of such an attack.  For in person transactions, where instant confirmation is most needed, the economics of such an attack are already not viable.  For online transactions, counter measures could be as simple as resorting to full confirmations in the event of a successful double spend.

(btw, some on this thread have mentioned listening for conflicting transactions…but that's not actually how it would work…you would receive your transaction through the network and then you listen for additional nodes reporting that same transaction…what you want is a high percentage of nodes reporting your transaction…if they report your transaction, it means that they consider it to be valid (and would have discarded any conflicting transaction)…you'll want to place more weight on mining nodes if you can determine them since you'll want to see that there are miners working on putting your transaction into a block)

They aren't _much_ harder to pull off with pools being the way they are. Double spends aren't exactly easy as cake to pull off, and they will generally only affect a small number of people. Making an insurance company to reduce the threat is laughable. Merchants could merely add a small fee to their products to cover any potential loss.

Legislation is very expensive, probably more expensive than designing a big computer to compute SHA2 hashes. Not to mention there is no one-world government yet. Attacking the exchanges doesn't stop the network, especially if it's ubiquitous.

Maybe that's because they are _much_ harder to pull off?

Besides, if any such "agency" would really want to bring down Bitcoin, they could do so much more easily by influencing legislation, attacking the exchanges, spreading more FUD,...

I find it funny to assume that anyone with the power to quickly build a 30.000 GPU cluster just for the purpose of messing with Bitcoin, doesn't have any better, cheaper and slightly more subtle means of severely harming Bitcoin.

Worrying about double spending is such a waste of time. Ooh someone might be able to pull it off once every 10 minutes assuming they're lucky enough to get a block. The odds of this realistically being attempted go down as the network hash power goes up. So if bitcoin is popular, it isn't much of an issue. But if bitcoin is popular, it might garner the interest of malicious agencies who can:

* Prevent some or all transactions from gaining any confirmations
* Prevent some or all other miners from mining any valid blocks

No one is going to double spend on a coffee or to buy a coke from a vending machine. Even if they do, it isn't as if it is a constant threat. Any larger purchases can always wait until 6 confirmations or whatever seems prudent. The much bigger issue is being able to mess with EVERYBODY as in the above two scenarios which are often not brought up in discussion around here.

Sounds good for a USD payout - if I were a retailer, I'd probably go with that option and a weekly/monthly payment would be fine.  Indeed if you're offering BTC conversion to USD at the market rate at the time of the transaction, together with a guarantee of non-repudiation of transactions then I think you've got all possible worries of a retailer covered - (chargebacks, delays and BTC volatility). If I were a small retailer, I'd be much happier paying a small percentage than trying to figure out that stuff for myself.

There isn't really any cost associated with that attack. As to time: I'm pretty sure someone would do it. You have a vending machine sitting somewhere and the prize of tricking it is a free coke. How can any decent hacker turn down this challenge? Someone would write a tool to perform the attack - not for the money, but because of the challenge. Then the tool is out there and the next thing you know is that people start using the tool all the time to get free soda from your machines. (I'm talking about a tool for the simple attack here - such a tool could be written, which would basically just need the IP address of the vending machine and the rest would be automatic.)


That's true - but that's what I said, that you need at least basic double spend protection and can't just completely ignore the problem. (Because you could also set up that central vending machine server in a naive way which still opens you up to the attack.)

Thanks for the explanation. Now that I know the answer to all my geek questions, I will just sit back and agree with Steve: it's too much work for a pizza 

I'm almost positive this isn't how it works. There are orphaned blocks and short splits all the time. If half the network is working on 160543A and half on 160543B this doesn't make it easier for an attacker to rewrite 160543. Someone who knows this stuff please confirm.

Jan do you think someone will really spend all this time and expense for a $1 soda from a vending machine? 

But there's no need for every vending machine to run the bitcoin client.  They would just link up to a server with enough connections to monitor the network.  So the mobile phone is paying bitcoins to the server, not to the vending machine.

How would miners know.  No miner can be 100% certain they see all transactions from all nodes in the network at all time.  You may suspect it is true but you can't definitively know.  Worse if some miners accept the block and some don't then you have effectively reduced the hashing power on the longest chain.

Would be a good precursor to a 51% attack to break the "cohension" of the good miners by creating multiple "double spend blocks" and fragment the network hashing power into multiple sub-chains.

Given the limitations of bitcoin being a peer to peer network where no node can have 100% certainty that they have seen every transaction there is no solution to a Finney attack other than to required 1-confirm.

I agree with you, but, theoretically, the miners could see that this was a double spend attempt and mine the next block based not on your block, but on the previous one. This would create a fork and invalidate your chain (unless of course you have 51%). But allowing something like this would probably have lots of other implications...

Online gambling is an example where paying with 0-confirmation transactions would be nice (get started playing right away) and double-spend insurance/protection is necessary. Otherwise an attacker deposits, plays and double-spends in case they lost.

Also: If you don't do _any_ kind of double spend protection (i.e. don't monitor the network for conflicting transactions) it starts to become an even bigger problem. So if a vending machine operator wants to accept 0-confirmation transactions today, they would definitely need to monitor the Bitcoin network for double-spends. Not something your typical vending machine operator has the technical skills to program and set up, so out-sourcing this to a service provider in the form of an insurance definitely makes sense in my opinion.

If you just integrate the standard Bitcoin client into your vending machine, you would for example be open to a much simpler attack like this one: http://www.reddit.com/r/Bitcoin/comments/kmo2l/suggestion_bitcoin_confirmation_honeypot/c2lhfs1 .

Yeah... You're right. My post doesn't make sense

There is no method of enforcing a miner to include or not include a particular transaction.  The network specifically allows a miner to include whatever transactions he wishes to in a block.

I think you may be confusing nodes with miners.  Nodes will only relay the first transaction and ignore the rest.  There is no financial incentive to do otherwise.

Why would it matter which transaction a miner includes in the block?  If this is a 0-confirm attack then the attacker already has the merchandise.  He doesn't care which (if any) transaction ever gets included in any block.

I don't agree. Note that we are talking about conflicting transactions only. Which means that if I see 2 transactions spending the same coins from the same address, I will include the one I saw first. Seems like a pretty good strategy for me. Otherwise you can triple-spend, quadruple-spend, ...., N-spend. You just need to keep issuing transactions with higher fees than the others.

The decision strategy for non conflicting transactions can and should be based on fees.

Why? His block would be perfectly valid, he would not be violating any protocol rule. Transaction priority should not and probably cannot be defined by the protocol - each miner is free to make its own policy. We should not expect miners to adopt a policy that rejects a transaction for another that pay less fees, at least not when transaction fees become a substantial part of mining reward.


Apparently there's a feature in the bitcoin protocol that allows you to send a transaction with a lock which forbids it from being added to any block before a specified point in time. The main point of this feature is to be able to cancel the transaction before such point in time, if needed. Such feature is frequently mentioned on the heritage use case. (You could send a transaction to your heirs with a nLockTime and if the date approaches and you're still alive, or if you just want to spend it yourself instead of leaving it as heritage, you cancel the transaction)

No.

The transaction and block are valid. The only potential safeguard is hashing power and that just makes it more difficult but not impossible.  However one has to consider the value of the loss.  All forms of trade (cash, check, credit cards, gold, barter) involve fraud.  It will never be eliminated not in Bitcoin, not anywhere.

However the amount of fraud is what matters.  To have the ability to generate any more than a token amount of revenue in attacks requries a huge amount of hashing power and a large transaction.

So yeah if someone wants to perform a finney attack to get something that costs small number of BTC it is likely is impossible to avoid.  However the increased gain on their capital expense (hashing hardware) is not significant and that likely will keep most miners honest.  Large transaction should require 1+ confirmations.

I don't really seel much value in insurance because small transactions are unlikely to be double-spent and large transactions are likely uninsurable against a Finney attack.  It is precisely these large transactions which would be the target of a Finney attack (to justify the capital cost required).