Quote from: Fuserleer on May 31, 2013, 12:31:40 AM

Quote from: Gavin Andresen on May 31, 2013, 12:16:13 AM

How do you prevent Sybil attacks-- somebody creating a gazillion n-client and/or hatching nodes, and voting themselves lots and lots of new currency?

And how does a node choose a "random" node-- does every node know about every other node? If yes, then how do you avoid getting O(N^2) communication as the number of nodes (N) rises and every existing node must be told about every new node?

I'm composing an amendment to the OP regarding Sybil like attacks and the prevention of them as a few members have raised this point both public and private, I'll be appending it shortly after I've finished up some other tasks. Hopefully that will then give an idea how we handle it.

Selecting a random hatching node doesn't require the peer to know about all of them, or about any other client peers in the system. A voting peer can either select a hatcher from its currently connected peer pool (if there is one or more present) or send a request to a seeder node which has a collective store of all the most recent nodes within the system (as its seeding it is able to do this easily), including plain client peers, hatchers and other seeders. As peers and hatcher connections come in and out of this peer pool, that further massages the entropy of the hatcher selection.

With the voting system it is possible to have many hatchers, all obtaining votes from the client peers independent of each other, and deciding, independently also, whether to create a new currency unit or not. Currency regulation is determined by using the public ledger, so providing that all the hatchers collecting votes are close to being up to date, they will all be working to the same vote threshold.

As the system grows hatchers will be working with a subset of the total voting power in the system, but the required target volume can still be met and held.

Quote from: Fuserleer on May 31, 2013, 01:05:32 AM

Quote from: Qoheleth on May 31, 2013, 12:46:15 AM

Quote from: Fuserleer on May 31, 2013, 12:42:04 AM

The hatcher that is selected and the vote (yes or no) are handled by the client software. The actual wallet holder has no control over this at all.

That's meaningless from a security mindset. If it's open source, people can change the client software, heck, even if it's closed source, people can change the client software with enough effort.

Quote from: Fuserleer on May 31, 2013, 12:42:04 AM

If you were to grab the source and modify it to always vote yes, then even if there were only 100 other voters in the system, you vote can only skew the vote by 1%, which isn't enough to cause damage and will only push up the vote threshold over time.

So now we're back to "what magical algorithm are you using to stop Sybil attacks?"

I'll explain further, as no "magical" algorithm is needed to prevent runaway creation volume of units, and to overcome nature of how it works to benefit, you would need to own, or control the entire network. That's all client peers, all seeders, all hatchers, to ensure that the fruits of your attack were beneficial, then its no longer decentralized anyway, so then it would die.

Anyway, lets say that current vote threshold is 50%, that is, 50% of the votes in need to be yes to create a new unit. To force a hatcher to create a new unit, you would need to have more than 50% of the vote power to that hatcher (disregarding any others in the system).

Assume that you have managed to pin down a few hatchers, and you flood them with votes from many clients to push the vote 50%+ so new units are created. That will likely move the created unit volume up past the required target the network, so hatchers in the system (including the ones you have pinned down assuming you don't own them) will adjust up from 50%+ yes vote, to say 75%.

You perform the attack again and again until the vote threshold is 90%+, that essentially cuts of the creation of the units, because the volume is ahead of where it should be, so no new units will be created until time catches up.

If you DO control the hatcher to always create a coin, you need the signed votes which are verified later, you can only create 60 units at a time, otherwise other hatchers and clients will reject it, and you can only create once every 60 minutes, otherwise other hatchers and clients will reject it.

Creation of a new unit (coinbase in BTC terms) has a record of all the yes voters, with their votes signed. When that block goes out in to the wild and is re-verified by other hatchers, those voting nodes can be contacted and asked if they indeed voted yes to create that unit, if you control all the voters to that hatcher too, then yes you could falsely create a 60 units.

So you have created 60 units ahead of time, dishonestly, but unless those units are distrubuted as required by the system, those units will again, be rejected by others in the network.

I could continue, but that should give you an clearer idea how its "difficult" to game it unless you are running a lot of the network both in client peers and hatchers.

A proof-of-work or proof-of-stake system are the only known ways to stop someone from running a lot of client peers or hatchers in a decentralized system in order to block transactions or double-spend. I do not see any new solution to the Byzantine Generals problem in your answers.