Quote from: josvazg on April 10, 2013, 11:26:05 AM

Then this paper should be wrong:
http://people.scs.carleton.ca/~clark/biblio/bitcoin/Karame%202012.pdf
...

Ok, I already completed this paper.

It basically demonstrates both theoretically and empirically that it was possible and CHEAP for them (no mining at all) to make double-spends to a faked vendor (themselves of course). They just made sure the attacker's peer connected to the vendors peer while they maintained some (FEW) helpers at some points of the network.

Those helpers had a direct connection with the attacker daemon so that they could receive the order "to inject" the BAD transaction on the network when A needed it, that is just a few moments before or after A fakes the GOOD transaction to the vendor daemon.

Interesting facts they proved:
1- Some blocks can take up to 40 minutes to form.
2- Even after 2 seconds of head start of the GOOD tr. vs the BAD one, just 2 helpers used to guarantee the success of the attack most of the time so that the bad transaction is confirmed in the next block and the merchant is scammed (with no company or individual to sue).
And after 1 second the success is sure with JUST 2 helpers!!
Not really that expensive to have two or three modified bitcoind arround, a botnet of a few tenths of processes is easy and cheap to deploy.

3- Bitcoiners suggestion to use a "listening period" is NOT a definitive solution and can be defied by increasing the number of helpers (but still under 10 in most tests).

4- Bitcoiner's suggestion to use observers is only useful while increasing merchant bitcoin deployment costs setup, while a easier solution exists...

The problem here is simple...
Why does bitcoin peers SILENTLY drop double-spending transactions when they detect them?
It is silly they should just REPORT the invalid transactions to their peers (while reject them both in this block)

This is what the paper suggest as the solution just use an alert message (that the protocol already defined) to notify fraudulent transactions.

In this way a merchant, with an typical standard setup and no more hassles, can rely on bitcoin to make "instant" payments:
- In a shop, just make the receipt printer wait 6-12 seconds (configurable by the vendor with a default value considered "safe enough") so that any double spending attack is detected and notified in that time OR print a warning otherwise... so that the merchant can make the client wait for the police...

I prefer this solution to the one I was proposing and that was much more complex.

Anybody knows if these "double-spending report alerts" are implemented TODAY in the protocol?

(If that is the case I would have to admit that bitcoin does INDEED support "instant" transactions securely enough,
if not, why is this not implemented already?
what is the problem for such a small change with so obvious returns to be rejected?
still to much self-complacency?)

AND THANKS to VeeMiner FOR POINTING me to this paper!!!