Quote from: ffe on April 21, 2011, 04:12:12 PM

Quote from: BlueMatt on April 21, 2011, 03:10:21 PM

Keep in mind that a node will not forward a transaction if it has already seen one that conflicts.

This is why in a previous post I'd recommended we do pass an indication of a double spend.

And so opens the door for massive DDoS potential. Better to just not.

Quote from: ffe on April 21, 2011, 04:12:12 PM

Quote from: ffe on March 19, 2011, 01:43:21 AM

... the _only_ person who can double spend is the owner of the coin (since only he knows the private key). The only time clients see a double spend is if the owner is purposely being malicious. It is therefore reasonable to drop _both_ the original and the second transactions if a double spend is seen within a window of time. Further, the double spend "event" could be bundled (both original transactions included in the bundle as proof of the double spend) into a transaction that locks that coin out for a long time (remember, we have proof of malicious intent so we would be justified in locking out the coin for say 10,000 blocks or more).

After the [15 second] window of time expires the second transaction is simply ignored. At this point we don't want to lock out the coin because we don't want to leave an opening for the original owner to cancel the original transaction. We would need the window to be large enough that we are very confident most clients have seen it yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example. So, waiting 30 seconds without seeing the coin lockout transaction would assure the merchant no double spending happened.

Interesting idea, but I disagree. It is possible that it could happen reasonably if a user copied their wallet.dat (fist rule of software: your users are out to break your program).

Quote from: creighto on April 21, 2011, 03:45:43 PM

If such things start happening, the methods of double spend checks would become more complicated, and fewer vendors will be willing to accept unconfirmed bitcoin transactions without ID and/or insurance. The fraudulent user is then in a digital arms race that he cannot win, and repeatedly doing these kinds of things is still going to get you caught eventually.

Without ID/insurance and at that point you might as well just wait the 10 minutes. Also, it becomes hard online and if you want to actually be sure you have to have a person check. Again, at that point, just wait the 10 minutes.

Quote from: creighto on April 21, 2011, 03:42:02 PM

The regular client doesn't perform a check of the live transaction queue, but it could be done. I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers. And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good. Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable. This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.

Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.

That is an interesting idea. I'm not so sure that gives you that good of certainty. If there was a malicious user, it would be their goal to send out the tx they dont want to see accepted as much as possible through the network. Although it would provide protection, some users would still exploit the system. Whether that is enough for places to take the losses, I don't know.

In any case I don't see a future where every normal user is using standard bitcoin nodes. The network probably won't handle that and I doubt merchants will want to run their own bitcoin instances all over the place. Much more likely is a set of payment processors using bitcoin as the currency of exchange.