Topic: List of Sybil Attacks and Attackers (Read 1605 times)

Using wallet balances to verify full nodes to prevent sybil attacks

Sybil attack to change ledger entries - No risk, completely destructive

Description: A Sybil attack is a person creating a lot of nodes on the network, possibly thousands on a single machine, in order to get a disproportionate vote on networks where each node gets an equal vote.
Defense: The RaiBlocks voting system is weighted based on account balance. Adding extra nodes in to the network will not gain an attacker extra votes

https://github.com/clemahieu/raiblocks/wiki/Attacks

Can I also post proposed solutions against Sybil attacks in this thread?

Here's an interesting read:

http://www.cse.psu.edu/~tfl12/paper/Sybil.pdf

Sybil-resistant DHT routing

https://www.cl.cam.ac.uk/~rja14/Papers/sybildht.pdf

Chainalysis Roadmap
PRIVATE AND CONFIDENTIAL APRIL 2015

 
2
Chainalysis Roadmap PRIVATE AND CONFIDENTIAL
Chainalysis Roadmap
 
30-day roadmap:
 1.
 
Shift to production environment with redundancy, load balancing and trivial scalability 2.
 
Drill down into transfers between clusters using the transactions view. This will allow the user to see transaction by transaction what funds were sent between two entities. There will be both a table view and a time series histogram of the entire transfer history to allow for the user to see how the flows to and from each cluster have changed over time. The histogram will also provide the user with the ability to focus on a particular time 3.
 
Organization / User separation of privileges: a.
 
Charts are per user b.
 
Names are per organization c.
 
Introduction of Tags (also on organizational level) - see below 4.
 
Introduce category tags. This is where we can expose certain services as being a certain type of entity on the Bitcoin network, i.e. Payment processors, dark markets, gambling sites, etc. These types of tags will be included in the GUI as well as offering easy to integrate API support 5.
 
Ability to search by transaction hash, cluster name, category etc. This will allow for faster investigations via known clusters of interest but also for the API to answer specific questions about transactions or entities of interest. Part of this also allows for easier integrations through the API with the ability to support transaction hash lookups. 6.
 
Ability to merge and split clusters as a user sees fit and for these to be stored in their account. Will make investigations easier and improve the accuracy of any API calls that are made using that user account.
60-day roadmap:
 1.
 
Unconfirmed transactions support through the API. Currently customers need to parse transactions and submit the address from the inputs of the transaction to the API to get a response. With a mempool of unconfirmed transactions the user will only need to pass the transactions hash through the API. Clustering over unconfirmed transactions will take place in real time. 2.
 
Shared multi client repositories for known bad actor reporting as well as for subscribers own addresses enabling 0-risk 0-conf transactions as well as enabling travel rule checks. 3.
 
CSV exports of all data. 4.
 
Macro support: Macros enable automated / guided merges of clusters as well as creation of investigation graphs for funds flow / origin. These allow the user to specify certain parameters such as only looking at min flow / max flow, specific entities or size of transfers to recreate a graph to look further into an investigation. This will also feed into the accuracy and precision of API calls as users can store the results from this analysis. 5.
 
Profiling API improvements a.
 
Min / Max flow b.
 
Country of Origin for a transaction c.
 
ToR / VPN 6.
 
Addition of more intelligence sources and presentation of origin of intelligence and references.
90-day roadmap:
 1.
 
Creation of more macros based on user feedback and data 2.
 
Transaction groups / sub transfer view enabling clear visualization of automated investigations with flow of funds etc. 3.
 
User permission graduation (can assign (group) names, can merge, can assign tags, can view)

 
3
Chainalysis Roadmap PRIVATE AND CONFIDENTIAL
Commercials
 
 Account costs
 
Investigator Compliance
(Coming soon)
Institutional
(Expected Q2 2015)
$179
 per agent / month Billed annually or $199 month-to-month
$329
 per agent / month Billed annually or $349 month-to-month
$479
 per agent / month Billed annually or $499 month-to-month Unlimited investigations Naming of entities Unlimited investigations Naming of entities Access to shared fraud databases Unlimited investigations Naming of entities Access to shared fraud databases API access
In Development and Coming Soon
 Customized Clusterization Macro access Compliance exports Customized Clusterization Macro access Compliance exports Tagging Advanced Profiling API Lightweight watch-only accounts


http://www.scribd.com/doc/263321318/Chainalysis-Roadmap

MIT’s Bitcoin-Inspired ‘Enigma’ Lets Computers Mine Encrypted Data

Uses security deposits and fees to avoid Sybil attacks.

https://www.reddit.com/r/Bitcoin/comments/3bmbi5/mits_bitcoininspired_enigma_lets_computers_mine/

Note that this paper dates from 2006, predating bitcoin.  It does not reference Hashcash.  You might look for recent work protecting replicated databases from Sybil attacks.

Main problems I'm trying to investigate:

1. Bob can pay Alice to run a Bitcoin full node, as part of an incentives scheme to increase Bitcoin node numbers. Bob's payment is intended to be enough to cover Alice's costs and produce a small profit.

Alice can decide that it's too much effort to run a Bitcoin full node. She decides instead to put up a node which sends out data to suggest it is a full node, but is in fact an empty shell. Her fake node provides no data to the Bitcoin network, but is still paid.

While some will play fair, it takes around 1 in 100 people to put up many fake nodes to profit from an incentive scheme to put the incentives scheme at risk of failing.


2. Bob can pay Alice to run a Bitcoin full node, as above.

Alice decides that she will put up hundreds or thousands of full nodes and earn a small profit from lots of nodes.

Now Alice has the ability to snoop on millions of transactions. She decides that she will keep track of all the transactions and use her data to make more money by selling that data to exchanges and banks looking to track users and negatively taint coins if they have been involved in illegal transactions at some point.


3. A combination of 1 & 2.

There are other areas that might come up during the review. But these are the main areas I'm currently focused on.

OP perhaps you can explain the problem in more detail as I'm not familiar with the issue.
Why would a sybil attack apply if blocks must be solved anyway by miners?  Is it a
consideration when brand new nodes are joining, or what?

A Survey of Solutions to the Sybil Attack


http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.6395&rep=rep1&type=pdf

Thanks.

I was going to use the second post for some additional info. But decided I didn't need it after reading your post.

Deleted

I don't know if it applies here, but there is a rule forbidding people from posting reserved or any other placeholders in the alternate cryptocurrencies announcements section. I have not seen many threads with reserved posts in this section, but it seems pointless making them.

Cross post for reference

Sybil attacks are a major barrier to Bitcoin node incentive schemes.

I'm researching Sybil threats, attacks and mitigating developments. It could turn into a BIP, but that is not clear at this stage.

####################
# WORK IN PROGRESS          #
####################

Definition

Large-scale peer-to-peer systems face security threats from faulty or hostile nodes.

Bitcoin is a large scale peer-to-peer system and one of the longer-term threats to its decentralized nature is the creation of large scale 'dishonest' nodes, either for traffic analysis, to slow down the network, to steal or to control the network. As corporations face cyber security threats, Bitcoin faces many cyber threats and Sybil attacks are one attack vector that requires greater attention.

Redundancy can reduce these threats. If a single entity can create multiple identities, it can control or influence a substantial portion of the network, thereby undermining this redundancy. [Douceur, 2002]

"...without a logically centralized authority, Sybil attacks are always possible except under extreme and unrealistic assumptions of resource parity and coordination among entities." [Douceur, 2002]


Types

*Isolating nodes to create the environment for double spends.
https://bitcointalksearch.org/topic/m.117573

Examples from BitTorrent: Real-World Sybil Attacks in BitTorrent Mainline DHT
http://www.cs.helsinki.fi/u/lxwang/publications/security.pdf

* Data gathering
-> Ellipitic (elliptic.co)
-> Tradeblock
-> Chainalysis

* Revealing Bitcoin users IP addresses and identities

Attempts on Bitcoin

Chainalysis
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

Resistance and Prevention proposals

* Proof of work, Adam Back's Hashcash paper;  a denial of service counter-measure, 2002, has been used by Bitcoin to deploy mining. The purpose: mining costs money and is therefore a cost barrier to anyone wishing to launch attacks.
http://www.hashcash.org/papers/hashcash.pdf

* Collateral, used by Dash (Darkcoin) to create a cost barrier to running nodes and therefore a barrier to launching sybil attacks. Duffiled and Diaz, 2014.
https://www.dashpay.io/wp-content/uploads/2015/04/Dash-WhitepaperV1.pdf

* SybilGuard: Defending Against Sybil Attacks via Social Networks, Yu, http://www.math.cmu.edu/~adf/research/SybilGuard.pdf

* MIT’s Bitcoin-Inspired ‘Enigma’ Lets Computers Mine Encrypted Data

Uses security deposits and fees to avoid Sybil attacks.

https://www.reddit.com/r/Bitcoin/comments/3bmbi5/mits_bitcoininspired_enigma_lets_computers_mine/


Please list any suggestions for preventing attacks, or links to appropriate resources that are relevant.  Thanks.