@s{quotedtext}
@s{quotedtext}
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.
@s{quotedtext}
@s{quotedtext}
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).