Hacker News Reader

Comment by wyager | Hacker News Reader

>Sure, if your willing to wait 20+ minutes to get your drink.

This is a fundamental misunderstanding people have about Bitcoin.

A bitcoin before a block confirmation ~ A credit card before 180 days.

There is a small possibility of "undoing" a transaction before a block confirmation, just like there is a small possibility of a customer doing a credit card chargeback before the credit card payment clears. However, it's a pain in the ass (even moreso with Bitcoin), isn't reliable with Bitcoin, and almost no one ever does it.

For small transactions like buying soda from a vending machine, waiting 2 seconds for the transaction to propagate is more than enough.

The only time I would ever wait for a block confirmation is if I was doing a transaction in the thousands of dollars range.

View on HN

There are several ways you can implement this, but unless you wait occasional double spends are fairly easy to pull off. To put it simply unconfirmed transactions take a while to propegate and don't instantly decrement your wallet. True a single small transaction might not seem like much, but it's anonymous and even a small chance of success chance is going to be with it to some people.

PS: A 51% attack is only needed to counter confirmed transactions unconfirmed transactions have little protection and take a while to get confirmed.

Reversing an unconfirmed (0-confirmations) transaction is easy to do, with a supposedly 10-20% success rate, and doesn't depend at all on hashing power. Just broadcast a 2nd conflicting tx that pays a higher fee (most nodes won't re-broadcast a conflicting tx that comes in later regardless of the higher fee, but some will re-broadcast it).

But that's different from a double-spend, which is reversing a tx that already has 1+ confirmation, through a chain reorganization.

The economics and technicalities of this are analyzed extensively in the latest Ethereum blog post https://blog.ethereum.org/2014/07/11/toward-a-12-second-bloc...

In the pilot we are just forwarding the transactions as they come. But in future we may send extra information if we receive a transaction trying to reuse already used transaction. That will help in the race condition you described: 1. wait for a transaction 2: wait some seconds if there comes an alert about other transactions trying to consume the same inputs.

That might help, but this is an issue which can be addressed after the pilot starts.

That's the type of attack I was thinkining of, but if your not calling it a double spend what's the terminology?

Double spends would be hard enough that it is not worth it for low-value transactions. The operator of Ghash would have a 30% chance of pulling it off, but that problem would be solved if hashpower/pool concentration gets solved.

You don't need lot's of having power a new transaction with a higher transaction fee can get you there ~10-20% of the time. For small anonimus transactions like a vending machine that's not a problem. Add a slick UI and an suddenly lot's of people are going for random "Free" soda.

I think there are a mix of reasons why existing double spends are working, certainly things have gone wrong and there are various ways to do it - e.g. Eligius does not follow the same rules as everyone else and that's exploitable by double spenders. However that's not fee related.

Reply on news.ycombinator.com