Bitcoin Forum
June 23, 2018, 03:01:45 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
   Home   Help Search Donate Login Register  
Pages: [1]
Author Topic: Cancer nodes attack - need explanation  (Read 1201 times)
Jr. Member
Offline Offline

Activity: 52
Merit: 0

View Profile
February 04, 2012, 05:02:58 PM


i saw on that network can be attacked using multiple clients with different IPs, but i got problem anaylzing those two points:
* The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
* If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack.

Main problem for me is - how double spend attack will be performed? Isn't it working like that: when i download any block to my chain it is checked for double spends (checks are performed for every single TxIn) ? So even creating own blocks by attacker shouldn't allow that here..

Hero Member
Offline Offline

Posts: 1529722905

View Profile Personal Message (Offline)

Reply with quote  #2

Report to moderator
The World's Betting Exchange

Bet with play money. Win real Bitcoin. 5BTC Prize Fund for World Cup 2018.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Offline Offline

Activity: 874
Merit: 1000

View Profile
February 04, 2012, 11:00:08 PM

Main problem for me is - how double spend attack will be performed? Isn't it working like that: when i download any block to my chain it is checked for double spends (checks are performed for every single TxIn) ?

a bitcoin client only cares about the first transaction it sees.  if a later transaction is a double-spend the client simply ignores it.   so a race attack has the attacker sending to you (and only you) a transaction.  Then a fraction of a second later, for instance, the attacker sends to the rest of the network a second spend using those same funds.  there is a decent chance then that the attacker's double-spend transaction will get mined, and the transaction your client saw will never get confirmed.   that is why it is called a race attack -- the attacker is hoping that the double-spend transaction reaches the miner's nodes first.

as far as the weakness described in the wiki, if an attacker controls a lot of nodes (and announces those nodes to you as peers) then the race attack becomes a little more easy to perform -- as the nodes under the attacker's control will not relay the initial spend.  if your client happens to have so many cancer nodes that it happens to connect only to those nodes controlled by the attacker then the attacker has full control over you -- as you aren't seeing blocks or transactions relayed by any honest nodes.

a merchant that wishes to accept on 0/unconfirmed can (mostly) protect against a race attack by doing two things:
1.) do not run as a listener / do not accept incoming.  if the attacker doesn't know the merchant's ip address and the merchant isn't accepting incoming connections then the attacker's double-spend often loses the race in reaching the merchant.
2.) manually specify which peers to connect to and connect to many addresses known to be for miners.  thus it isn't likely that the merchant will learn of a transaction that will disagree with transactions (most) miners see as well.

because not many merchants accept on 0/unconfirmed there isn't much built (yet) to help protect merchants from race attack risk.   one protection would be having listening nodes out there so the merchant would know within seconds about any attempts to double-spend.

incidentally, even if a merchant has protections against a race attack, the merchant is still at risk of losing to an attacker performing a finney attack (where the attacker mines and performs the double-spend when a block gets mined.)
Pages: [1]
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!