Comments on: Dissecting the Bitcoin Double Spend Attack

By: Bitcoin and Morality : Moneydick

Bitcoin and Morality : Moneydick — Tue, 25 Sep 2012 23:44:26 +0000

[...] double spend problem is real, but difficult to perform (read more). Ten minutes is all that is required, or about 6 confirmations, to trust a transaction of coins [...]

By: enmaku

enmaku — Tue, 25 Sep 2012 02:56:39 +0000

Valid point, I'd forgotten that in order to connect to a given miner you'd need to know their IP and most pools don't make a point of publishing their public IPs…

By: Dissecting the Bitcoin Double Spend Attack | Bitcoin News Bits - CoinBits.com

Tue, 25 Sep 2012 01:37:27 +0000

[...] by enmaku link 3 [...]

By: Bitcoin Dissecting the Bitcoin Double Spend Assault - Bitcoiney Bitcoin Website Directory

Tue, 25 Sep 2012 01:30:10 +0000

[...] by enmaku [link] [eight [...]

By: David Perry

David Perry — Mon, 24 Sep 2012 15:20:29 +0000

Also, to my knowledge no one has yet performed a Finney attack, even as a proof of concept. There's nothing in theory to stop it from happening but it's a lot harder to pull off than this one. The Finney attack can also be mitigated by simply increasing the network hashrate since it relies on solo mining.

By: Anonymous

Anonymous — Mon, 24 Sep 2012 14:17:49 +0000

The Finney attack is another double spend merchants need to be concerned about when accepting on 0/unconfirmed. Thankfully that attack is expensive (about $1 per second that the attacker needs to hold a solved block) so the Finney attack is not economically viable against most merchants.

By: Anonymous

Anonymous — Mon, 24 Sep 2012 14:15:17 +0000

The miners and pools don't always allow direct connections, and even if they did, there's no knowing by the merchant if the miner or pool ended up rejecting that merchant's transaction such as what would happen if the attacker had already sent to that miner the double spend transaction.

By: David Perry

David Perry — Mon, 24 Sep 2012 14:11:06 +0000

They would still be racing the clock since they can't be connected to every miner. It would narrow the odds but it's still possible that the miner/pool that solves the block will have received the bad TX first AND not be a miner the merchant is connected to.

Being more connected, especially connected to miners, helps but doesn't eliminate the issue. The real fix is to poll for the conflicting TX at multiple communicating nodes.

By: Gary RoweRowe

Gary RoweRowe — Mon, 24 Sep 2012 13:50:24 +0000

So what would happen if the merchant was only connected to trusted miners? It would seem that only transactions that have found their way into a block will be reported and the merchant can be sure that the 0-confirmation won't be invalidated by the scammed transaction that must appear later by design.