# Gavin Andresen
# 2011-05-12 16:48:24
# https://bitcointalk.org/index.php?topic=8051.msg117573#msg117573

@s{quotedtext}
@s{quotedtext}
 @p{brk}
That's actually a very hard attack to successfully pull off; I file it under "theoretically worrisome, but practically not a high priority." @p{par}

It is hard because: @p{brk}
  + 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. @p{par}

  + 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. @p{par}


@s{quotedtext}
@s{quotedtext}
 @p{brk}
Putting a few addnode=...  to connect to trusted nodes (with static IP addresses) at startup in your bitcoin.conf is a good idea.   @p{par}

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). @p{par}