Sybil resistance

[sdbondi]

This proposal is (tick applicable):

• [ ] A new feature
• [ ] An extension to an existing RFC/proposal
• [x] An alternative approach to an existing RFC or proposal

Change log

Date	Changes
25 Aug 2020	Initial

Goals

What problems is this proposal addressing?

Attack vectors

A sybil attack is possible when a malicious actor is able to create many network identities to gain disproportionate (>= 51%) control of a network. In a PoW blockchain network, there is a (presumably prohibitive) cost in being able to produce valid blocks at the network difficulty. However, having >=51% control of a network allows other "shenanigans" that an attacker can be exploited. These are (there are probably more):

• Increasing the likelihood that behaving nodes are only connected to bad nodes (eclipsed)
• Refusing to relay blocks and transactions, effectively disconnecting the node from the network
• Only relaying blocks that the attacker creates, effectively forking the network (double-spends)
• Filtering a wallets view (especially if wallet accepts zero confirmations) to allow double spend

Problem

There are currently no known ways to outright prevent a sybil attack in a fully decentralised network. Mitigation comes down to making the cost of performing the attack not worthwhile.

A network identity on the Tari network is a <NodeId, Address> pair. The NodeId is simply a hash of an ECC public key. The address may be an onion (v2 or v3), ipv4, ipv6 or DNS address. In the case of <NodeId, onion address> pair, there is basically no cost in producing a new network identity (an v3 onion address is just a public key). Similarly, blocks of IPv6 address space are extremely cheap or even free.

A number of network "roles" may exist on the Tari network, namely: BaseNode, Client and ValidatorNode. A Client does not take part in consensus or message routing and so has nothing to gain by creating many network identities. A ValidatorNode requires a base layer transaction to register (see RFC-0322) and so already has a cost associated with it's participation on the network.

This issue specifically addresses concerns around the BaseNode role.

Description

I propose a set of rules applicable to the address of a base node are applied:

1. A node may not connect multiple nodes with the same IP address (different port) at a time*.
2. A base node advertising an onion address will not be accepted by any other node
3. A node may not connect to an IPv6 address within the same /40 CIDR block (based on pricing here: https://www.arin.net/resources/fees/fee_schedule/)**

* Bitcoin applies this rule to /16 IPv4 blocks (255.255.0.0) ** Or exclude IPv6 entirely

[stringhandler]

It would be useful to add the attack vectors of not implementing Sybil resistance here

[sdbondi]

Agreed - added a heading for it.

[SWvheerden]

Is there reasons why we would force nodes to run only run tcp? I can think of a lot of reasons why its advantages to run the nodes in tor mode.

Whould it not be better to combine the two networks, have nodes run tcp and tor?

[sdbondi]

@SWvheerden I'll write this up at some point - but basically, you can create practically infinite tor addresses so there is no way/point in blocking a tor address - creating many identities on the network is cheap/almost free (>100s on a single machine). With TCP you can at least exclude IP addresses and there is a cost in getting more IPv4 addresses (IPv6 is another story).

Tor will still be allowed for "clients" that don't take part in consensus (e.g. wallets)