fwiw, those seem to apply to only a single destination, and any node can sybil up as many destinations as it wants, right? `announce_cap` seems more relevant
is there a place where you've written down the threat model reticulum is intended to defend against? it's hard for me to evaluate its security measures without that context
The threat model would be highly dependent on the carrier used. For example, if you're using LoRa an adversary would be using far different methods of disruption when compared to a traditional overlay network.
i think physical-layer disruption like lora jamming is kind of a separate consideration, but physical-layer traffic analysis might not be
i had misunderstood you to be saying that the second reticulum node ever was at your house, so i had assumed you were the author
one malicious peer can have as many sources as they want. don't even need a botnet of IPs.
The link you posted seem to guard against flood of sinks on the distributed routing, but there's no mention of source flooding.
The blockchain approach basically bootstraps said authority, and comes with tons of additional baggage. It's the only one I'm aware of that has real countermeasures to Sybil attacks though (in a sense; 51% attacks can also look a lot like a Sybil attack with the right glasses on)
there are a lot of possible approaches to the problem, though
hashcash for announcing new destinations is one possible measure
reserving most of the bandwidth for established connections to which both parties are indicating their continuing enthusiastic consent is another, and one which the circuit-switched pstn does implicitly, which is why your phone calls wouldn't drop or skip when there was a commercial break in prime-time tv. reticulum seems to do this by reserving 97% of bandwidth for non-announcement traffic, though i might be misunderstanding
the agorics 'digital silk road' paper from 01995 (unrelated to the later darknet market) describes another approach: include a source route and postage on every packet, with each network provider deducting however much postage it feels like deducting, and keeping track of bilateral account balances with each peer network (postage sent minus postage received). if the postage runs out, your packet gets lost, and the sender can choose to try resending it over the same route with more postage or routing it over a less expensive network. periodic cash settlement between network service providers zeroes out any persistent imbalance in cash sent and received: http://www.cap-lore.com/Agorics/Library/dsr.html. i don't think this has ever been implemented, though current nsp peering agreements do resemble it to some degree. the original paper suggested using eft for the periodic settlements, but nowadays you could very reasonably do it with something like ether
you can supplement the established-connection-prioritizing mechanism with a granovetter-diagram introducer mechanism: if alice has an established connection to bob, and bob has an established connection to carol, bob can dedicate some of his bandwidth on those two connections to passing messages between alice and carol. he can do this either completely at the application layer, with no support from lower layers of the network, like an irc server or turn server, or potentially with support from the network layer to find a more efficient and reliable route. (reticulum seems to support this; bob can pass alice's destination to carol or vice versa, which the manual seems to say eliminates the need for the announce mechanism, though i don't yet understand how the protocol works.) this allows bob to prioritize such connection requests using information that isn't available at the network layer, such as whether alice and/or carol have passed a captcha and/or are paying him, who they were introduced to him by, who they've introduced him to in the past, and what valuable data they've sent him. if bob repeatedly introduces alice to people she doesn't like talking to, she might cut off contact with bob, or at least look on his future introductions with a jaundiced eye and not allocate them much bandwidth