In the process of developing a protocol like Indranet there is an arc of development in which general ideas must give way to concrete algorithms that make the network usable, resilient and scalable.
One of the vague ideas that has become more crystallised relates to the way in which Indranet defends against what is generally known as the Sybil Attack.
Peer to peer networks in general have a vulnerability to the Sybil attack because of decentralisation - centralised defenses against this themselves become an attack vector, as we see this last year with Tor.
Tor project runs servers that provide a directory for the network, which effectively makes their directory servers worth attacking in order to lure users into offered relaying services that are corrupted, or indeed, even to being used as rendezvous points for hidden services.
Anonymity only amplifies the power of Sybil attacks, because new identities can be created and old ones cast aside with minimal cost, since identities are deliberately obscured, they have low value in the first place.
The main concept, of users paying for relaying service as a spam defense, and the lack of a default notion of relaying out to the clearnet are two things that Indra does to prevent this kind of abuse, only covers part of the problem space.
But how do we deal with the problem of relays spawning in mass numbers to grab session payments and then failing to deliver?
Well, this evening I have been thinking a lot about this and came up with some ideas how to achieve it.
Firstly, a novel use of a similar technique as used in LN, the Hash Time Locked Contract, which creates a delay between when a UTXO can be spent and then redeemed. Rather than a 2 of 2 multisig, Indra uses a single signature self-payment, which must have a delay in proportion with its size. A relay's license to operate on the network relates to this transaction, and it is maintained as a part of a relay's identity for its entire lifetime.
It works a little like Proof of Stake, but there is no yield, the relay simply gets their coins back at a later time. It adds friction to the setup of spammy relays.
This eliminates the low friction entry that a spammer requires, they have to lock up funds and the amount of time this buys them is proportional to the amount they lock up. Once it expires, they have to spend it back into a new lockup, and this must be continuously maintained for the operational lifetime of the relay, clients simply won't select it if it has no current lockup. The value of the lockup is based on its average level over the history since the initial TXID that becomes part of the relay's identity.
Second, clients share a random selection of their trusted nodes with a probability of selection based on their reliability. The odds of sharing a currently used node is proportional to the time since, so this does not deanonymise the clients.
Once a day or so, clients send out such an evaluation to relays that have a good record.
Relays privately keep the mentions count of relays of nodes as a comparison between their nodes, which in turn affects their ranking of peers as they advertise them in their peer discovery advertisments, most especially to clients.
Thirldly, the age of the initial TXID tied to a relay identity is also taken into account by clients. It proves the age of the relay, and thus it can be used as part of the calculation in evaluating the reliability of a relay.
The size of the TXID UTXO also has a small influence too, encouraging nodes to lock up more BTC on chain in order to gain a small edge in client selection.
Lastly, relays themselves evaluate the value of client submitted relay advertisments based on the age, freshness and volume of traffic passing from the client through their first and last hop sessions, preventing a sybil attack on client population.
In this way, Indra users are protected from evil relays.
More to come...