What's the plan about the Sybil attack?

[xor]

http://en.wikipedia.org/wiki/Sybil_attack

Short summary: An attacker could run tens of thousands of Bitcoin clients to isolate certain nodes from the network and then double-spend his coins.

The Freenet project has come to the conclusion that the only proper way to prevent this attack is to let the users explicitly decide who they connect to and encourage them to only establish connections with persons they know instead of strangers from the internet - "Darknet"-mode was born where to establish a connection you exchange public keys with your friends.
For usability it still supports hybrid mode where it prefers your friend-peers and fills up the remaining connection slots with strangers.

Freenet is about anonymity so preventing the sybil attack is crucial. And given that Bitcoin is about money, it seems to have the same importance here.

So IMHO the UI of bitcoin should
(1) Provide the ability to establish permanent connections
(2) Provide robust references to connect to your friend: It shouldn't be "IP:port" because many uses have dynamic IPs. It should rather be some public key hash which is used to query the IP of the node from the network...
(3) Encourage users to use friend connections so by displaying a warning if they have not enough permanent connections which explains the sybil attack

[Matt Corallo]

There are numerous topics on Sybil...the search function might be useful.  https://www.bitcoin.org/smf/index.php?topic=4335.0 is one such topic.

[Gavin Andresen]

Short summary: An attacker could run tens of thousands of Bitcoin clients to isolate certain nodes from the network and then double-spend his coins.

That's actually a very hard attack to successfully pull off; I file it under "theoretically worrisome, but practically not a high priority."

It is hard because:
  + targeting a particular node is hard.  The long-running nodes that you probably want to target (merchants or exchangers or e-wallet services, where double-spending could get you a significant number of bitcoins) will already have 50+ connections to legitimate nodes, and an addr.dat full of the addresses/ports of legitimate nodes.

  + you have to feed the target a bogus version of the block chain.  And you won't be able to feed them new blocks very fast, because difficulty is so high (unless you invest a ton of hashing power to generate bogus blocks... but that's stupid, you're wasting money mining worthless blocks so you can try to pull off a probably-low-value double-spend???).  Anybody you target is going to wonder why their transactions are taking so long to confirm and why their block count is falling behind everybody else's.

So IMHO the UI of bitcoin should
(1) Provide the ability to establish permanent connections
(2) Provide robust references to connect to your friend: It shouldn't be "IP:port" because many uses have dynamic IPs. It should rather be some public key hash which is used to query the IP of the node from the network...
(3) Encourage users to use friend connections so by displaying a warning if they have not enough permanent connections which explains the sybil attack

Putting a few addnode=...  to connect to trusted nodes (with static IP addresses) at startup in your bitcoin.conf is a good idea. 

For (3), detecting dramatic, statistically-nearly-impossible-normally changes in the hashing rate is a better way to detect sybil attacks.  That's on my personal "it'd be nice to have" list (because, as I said, I don't think this is a big threat).

[Enochian]

That's actually a very hard attack to successfully pull off; I file it under "theoretically worrisome, but practically not a high priority."

When Satoshi argues in his paper that Bitcoin can't be subverted unless someone controls over 50% of the computing power of the Network, he is thinking of an equal distribution of generating power amongst hundreds of thousands of nodes.

But what has actually evolved is a bit different than that.  As the difficulty increased CPU generation became no longer practical, so mining was pretty much confined to a small number of nodes mining on multiple GPUs. 

Then mining pools evolved, and the small number of pool operators controlled generation, not the pool contributors. 

People can switch which mining pool they contribute to almost instantaneously, and it is not beyond the realm of possibility that a pool operator could suddenly offer a great deal that would motivate over 50% of the generating power to switch to his pool, and fork the block chain.

This is a much greater risk than the Sybil attack, and could actually happen.

[error]

The thing is, as we've already seen, people will begin abandoning a pool that reaches 50% of the network hash rate.

[Enochian]

The thing is, as we've already seen, people will begin abandoning a pool that reaches 50% of the network hash rate.

So a pool operator reports half his actual hash rate, and offers double the going price per share.

By the time people figure out what is going on, forkage has happened, and people with transactions in the last N blocks get to spend their bitcoins again.

Security that depends on "people" voluntarily exhibiting a specified schooling or herding behavior is problematical.  Suppose "Anonymous" decides to fork the block chain.

[skittixch]

Suppose "Anonymous" decides to fork the block chain.

What would the repercussions of the pool operator doing this be?  would they not tarnish their reputation? would they have to be conspiring with a number of other people all poised to double-spend at a moment's notice?

It seems like the only way something like this could be pulled off (if I understand correctly) is in an organized crime fashion.  Exchangers teaming up to contort the market for personal gain, and the gain of their contemporaries...