Bitcoin Forum
December 06, 2016, 04:10:56 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Denial of Service using orphan blocks?  (Read 1201 times)
patvarilly
Guest

June 27, 2011, 04:53:42 PM
 #1

Reading through the bitcoin client sources, I can't find any limit on the number of orphan blocks kept in memory by a client, and I wanted to confirm if this is true.  The reason this seems odd is that someone could bring down any Bitcoin client of their choosing by connecting to them and pushing a constant stream of fake, large, difficulty-1 orphan blocks.  These never get discarded because it's in principle possible that such blocks live at the tip of a higher-aggregate-difficulty chain than the main chain (with a catastrophic collapse in difficulty at some unseen point between a putative fork and the orphan block).  At some point, the client's memory is exhausted.  With the rates at which people can hash these days with a GPU (say, 50 MHash/s to be conservative), it only takes about one minute to hash a difficulty-1 block.  Worse yet, you could precompute a few hundred of these and reuse them to bring down different clients, since orphaned blocks don't get relayed.

Is this a problem that has been discussed before?  If so, I would like to know what its eventual resolution was.

Thanks.
1481040656
Hero Member
*
Offline Offline

Posts: 1481040656

View Profile Personal Message (Offline)

Ignore
1481040656
Reply with quote  #2

1481040656
Report to moderator
1481040656
Hero Member
*
Offline Offline

Posts: 1481040656

View Profile Personal Message (Offline)

Ignore
1481040656
Reply with quote  #2

1481040656
Report to moderator
1481040656
Hero Member
*
Offline Offline

Posts: 1481040656

View Profile Personal Message (Offline)

Ignore
1481040656
Reply with quote  #2

1481040656
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481040656
Hero Member
*
Offline Offline

Posts: 1481040656

View Profile Personal Message (Offline)

Ignore
1481040656
Reply with quote  #2

1481040656
Report to moderator
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 27, 2011, 08:28:47 PM
 #2

Nodes do not accept blocks with difficulty below what they are expecting.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
June 28, 2011, 12:02:09 AM
 #3

Nodes do not accept blocks with difficulty below what they are expecting.

But do they accept blocks which are built off blocks mined in the very distant past when the difficulty was minimal?

I think they do.

As patvarilly says (and you overlook) the client can't gratuitously ignore new blocks which branch off very old blocks because that would hinder block chain reorganisation and the adoption of the "longest" chain if the network were split for a long time and then reconnected.

I haven't seen the problem addressed before. If such checks existed I would expect to see them in ProcessBlock() in main.cpp and there's nothing appropriate there. As far as I can tell, patvarilly's post is completely correct.

ByteCoin
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 12:37:27 AM
 #4

This could be solved by adding a few barriers into the client. Any time the world block chain is known stable, one could take a block number and hash pair and hard code it into the client a few days later. Once the client had passed a barrier, confirming the hash, it would not accept orphaned blocks for before the barrier or with difficulties below the barrier difficulty.

However, this brings up a larger point. The BitCoin client should be audited for these kinds of risks. As of right now, there are probably many ways a malicious attacker could temporarily disable or compromise the BitCoin network. (At worst, all they could do is slow down mining and transaction committing. Your money is safe. But that's still kind of bad.)

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
June 28, 2011, 12:46:39 AM
 #5

There are already checkpoints in Bitcoin.

Also orphan blocks aren't verified unless there's a block chain re-organisation. At which point the block chain is invalidated from where it forks and the entire thing is recalculated from there.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 01:01:06 AM
 #6

There are already checkpoints in Bitcoin.
Oh?! Awesome.

Quote
Also orphan blocks aren't verified unless there's a block chain re-organisation. At which point the block chain is invalidated from where it forks and the entire thing is recalculated from there.
His attack is not forcing the client to verify them but tricking the client into storing them in case there's a massive reorganization that we know will never happen.

A simple limit on orphan blocks will solve this. Since they're not propagated and the attack is on memory, it seems pretty little to worry about. You could handle millions of such blocks with no problem.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
patvarilly
Guest

June 28, 2011, 08:34:22 AM
 #7

A simple limit on orphan blocks will solve this. Since they're not propagated and the attack is on memory, it seems pretty little to worry about. You could handle millions of such blocks with no problem.

Not really: MAX_BLOCK_SIZE is 1,000,000, so I could make megabyte-sized blocks and send them your way.  Every thousand of these I send you chew up 1GB of memory on your end, enough to make anyone sad (and perhaps even crash the client due to a process limit).  To go further, if I send you a million such blocks, that'll eat up 1 TB of swap space, which would bring down almost any normal user's machine, and maybe even some miners (admittedly, sending you 1TB takes a while, but if you're a server machine and no one's watching, then who cares?).

Of course, you could just restart the client and be in the clear, but it seems pretty easy to defend against this kind of attack.  As you said, limit the number of orphan blocks you're willing to keep in memory.  Even better, when choosing which orphans to forget about, preferentially forget those that are linked to a previous orphan that you know about.  That way, you'll slowly build back to a genuine fork point, if that's what's going on.  But to do this properly, as soon as an orphan chain is linked into the main chain, you'd need to push a request for all the blocks following the tip of that orphan chain, since you may have received them before and chosen to forget about them.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
June 28, 2011, 12:24:22 PM
 #8

I'd like to see somebody work on a "shun ill-behaved peers" patch.

So if one of your peers sends you lots of garbage (blocks/transactions/addresses/whatever) you just disconnect from it and refuse to accept connections from it for a while.

The trick is thinking really hard about what is really 'garbage' and what might be honest, it-happens-every-so-often weird behavior due to block chain splits or other network events.

The goal would be to prevent a wide range of denial-of-service attacks.

How often do you get the chance to work on a potentially world-changing project?
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
June 28, 2011, 12:31:45 PM
 #9

I'd like to see somebody work on a "shun ill-behaved peers" patch.

So if one of your peers sends you lots of garbage (blocks/transactions/addresses/whatever) you just disconnect from it and refuse to accept connections from it for a while.
Now imagine what happens if some nodes have the patch and some don't, and it's possible to convince the ones that don't to forward the garbage they receive. It wouldn't have to be enough garbage to pose a denial-of-service threat in itself, just enough to trigger other nodes to shun the unpatched part of the network.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 28, 2011, 12:40:33 PM
 #10

Now imagine what happens if some nodes have the patch and some don't, and it's possible to convince the ones that don't to forward the garbage they receive. It wouldn't have to be enough garbage to pose a denial-of-service threat in itself, just enough to trigger other nodes to shun the unpatched part of the network.
Most of the garbage we're talking about wouldn't be forwarded (such as orphaned blocks). But you pose a very good point if the attack comes in the form of something that does cause node-to-node traffic.

It might be necessary to implement some of these changes with a trigger to implement them only after a certain block number is received. We then leave enough room for at least most of the network to update.

Another possible idea is to make a node submit some proof of work to connect to you. You can normally demand none or a very small one. But if you sense an attack, start demanding proof of work and start disconnecting nodes that place an unusual load on you. That would increase the computational resources an attacker would need, and it wouldn't affect existing non-malicious node-to-node connections.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
Pages: [1]
  Print  
 
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!