Bitcoin Forum
December 07, 2016, 04:35:57 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: What's the plan about the Sybil attack?  (Read 7891 times)
xor
Newbie
*
Offline Offline

Activity: 11


Freenet developer


View Profile
May 12, 2011, 02:39:06 PM
 #1

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

Developer of the Freetalk & Web Of Trust subprojects of Freenet - http://freenetproject.org
Freenet flog: USK@QeTBVWTwBldfI-lrF~xf0nqFVDdQoSUghT~PvhyJ1NE,OjEywGD063La2H-IihD7iYtZm3rC0BP6UTvvwyF5Zh4,AQACAAE/flog/12/
Bitcoin: 16CBmnNghHGJJ5T6DSUmNWxLhg97GDt7iU
1481128557
Hero Member
*
Offline Offline

Posts: 1481128557

View Profile Personal Message (Offline)

Ignore
1481128557
Reply with quote  #2

1481128557
Report to moderator
1481128557
Hero Member
*
Offline Offline

Posts: 1481128557

View Profile Personal Message (Offline)

Ignore
1481128557
Reply with quote  #2

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

Posts: 1481128557

View Profile Personal Message (Offline)

Ignore
1481128557
Reply with quote  #2

1481128557
Report to moderator
1481128557
Hero Member
*
Offline Offline

Posts: 1481128557

View Profile Personal Message (Offline)

Ignore
1481128557
Reply with quote  #2

1481128557
Report to moderator
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
May 12, 2011, 02:49:32 PM
 #2

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.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 12, 2011, 04:48:24 PM
 #3

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.

Quote
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).


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

Activity: 126


View Profile
May 12, 2011, 07:36:36 PM
 #4

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
Hero Member
*****
Offline Offline

Activity: 574



View Profile
May 12, 2011, 07:41:47 PM
 #5

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

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
Enochian
Full Member
***
Offline Offline

Activity: 126


View Profile
May 12, 2011, 08:37:59 PM
 #6

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
Jr. Member
*
Offline Offline

Activity: 57



View Profile
May 13, 2011, 05:08:08 AM
 #7

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...
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!