The real issue is a different one: How do you distinguish the claim of a Sybil attacker that he (and his 100 Sybils) were present and that 10 good peers were absent, from the counter-claim that the 10 good peers were present and the Sybils were absent?
Decentralizing the choice of location and even privacy-preserving range queries (who is close) are relatively easy to do with crypto, at least by comparison ;-). My 2 cents Christian On 06/30/2014 04:17 PM, Michael Rogers wrote: > In its current form the proposal relies on a central entity that > collects registrations, schedules meetings and gives points to > identities that participate in meetings. I wonder whether the central > entity can be removed. > > Cheers, > Michael > > On 30/06/14 15:04, hellekin wrote: >> A very interesting contribution of Carlo on Sybil attacks and how >> to avoid them in an end-to-end system. > >> == hk > > >> -------- Original Message -------- Subject: [SocialSwarm-D] Kill >> the pseudonyms just to handle sybil attacks? Date: Mon, 30 Jun 2014 >> 13:57:50 +0200 From: carlo von lynX >> <[email protected]> To: >> [email protected] > >> The scare that is being mounted concerning sybil attacks is making >> people think of radical solutions like impeding people to group >> their contacts into multiple identities, as described in >> http://forum.ethereum.org/discussion/1064/proposal-for-a-1-on-1-identity-system-protocol > >> Unless you care to have a Faceboogle-like feature of enforcing >> one key for one person, that is not needed. Sybil attacks are a >> problem solved at least in the GNUnet DHT if not in other advanced >> DHTs out there. > >> There is a very nice video of the 30c3 GNUnet Mesh presentation >> that is sitting on the c3voc server, waiting to be uploaded to >> http://cdn.media.ccc.de, that explains very well how sybil attack >> protection works - and it isn't even using any of the dozen social >> methods that have been proven to work in various papers. > >> So if you see anyone promoting their server-hosted technologies >> mounting nasty sybil attacks on end-to-end technology in >> comparison hit them in the face with some well-nurtured facts. > > >> ++++ Content of the web page follows, so you don't have to expose >> your interest ++++ > > >> Proposal for a 1-on-1 identity system protocol. > > >> Having an identity system that more or less guarantees that each >> person can only hold one identity at a time would allow many things >> that would otherwise be vounerable to sybil attacks to be built. > >> The method i'm proposing relies on having meetings organized where >> people authenticate each other. > >> Let's call the code/procedure an identity contract. > >> It would work like this: > >> 1. Register an name in the identity contract 2. Give your >> approximate positional data, this can be updated as you move >> around. > >> 3. A few days before the date, participants in the contract are >> randomly grouped together based on location, and get invited to a >> channel to communicate a meeting point. > >> 4. The people thus invited (maybe around 10-20 people, depending on >> how many are registered in this area) gather to the agreed upon >> meeting point. > >> 5. At the meeting, each participant signs a statement saying who >> they met at the meeting, so that every person is signed by at least >> one other who was participating in this meetup. > >> 6. The contract registers that the meeting was successful, and >> gives everyone involved one identity point. > >> This protocol relies on the fact that you cannot be in two places >> at once, and as long as you participate in a majority of your >> meetings, everyone can be sure that the identity you chose is your >> only identity within this system. > >> I have not been able to see any obvious attacks on this system, >> but maybe i'm missing out on something? Would love to hear your >> comments. -- SocialSwarm mailing lists: >> https://socialswarm.net/en/participate/ Websites: >> https://socialswarm.net/ https://wiki.socialswarm.net/ Liquid >> Feedback: https://socialswarm.tracciabi.li/ >> Digitalcourage, Bielefeld, Germany >> [email protected] > > > >
0x48426C7E.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
