-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi David,
I used to write the software that generated LimeWire's block list. We didn't try to block copyright enforcers, just spam and malware - so the problem was slightly different, but some of the things I observed might be relevant here. On 12/05/14 08:11, David Barrett wrote: > 1) How are these blocklists created? Last time I looked at gtk-gnutella's block list (several years ago) it contained comments describing the origin of many of the entries. You might find some of those entries in other manually maintained lists. For legal reasons we had to be able to justify the presence of every entry in LimeWire's list, so we started from scratch. We used a combination of network crawls and automated searches to find peers with anomalous behaviour, such as connecting to large numbers of peers, sending large numbers of queries, responding to nonsense queries, or responding to every query with the same file. This was a successful strategy - for a while. Some types of spam disappeared, but others quickly reappeared as the spammers realised we were blocking them via IP addresses and file hashes, both of which were easy to change as fast as we could block them (once per hour, by the end) using scripted could instances. > Q: What if you are leaching merely because there are so many > seeders? A: Rather than fully blocking incoming connections from > leachers on the list, just require that they share data with you > first before sharing any with them. Because they only way you get > onto the list in the first place is to have first downloaded some > data, you should always have some data to share. A newcomer downloads their first piece and gets listed; now they can only download from peers that want that one piece. What if there are no such peers in the swarm, or the newcomer can't find them? Do peers have to download pieces they don't want from listed peers just to test them? What's their incentive to do so? > Q: What's to prevent someone from DoSing the swarm by uploading a > list of every participant's IP and claiming it's a leacher? A: This > is a tricky one. But I imagine this could be addressed with some > combination of limiting the number of leachers any given IP can > report -- and how often they can report them. This would require > that an attacker have enough distinct IPs to make up a significant > fraction of the swarm to wage an effective attack. But if this > system were to combine state from across many swarms (eg, all > torrents tracked by that tracker), I imagine the number of valid > peers would dwarf the number of attacker peers very quickly. Amazon EC2 has some enormous IP ranges. Maybe create a second block list of addresses that aren't allowed to contribute to the first block list? ;-) Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTcNL/AAoJEBEET9GfxSfM9qIIAK/FvAAT0Bc8joHLZzili83q XvEnz5rmch2NRO+DKBPtYClYqur9qS8YmhCc4U+YOiCBC1HruaRS2Q38Lah0af0b KoTCW2dESwRi/5VSQi8flMvZzzdQ9OOFIbvQZecviIsQwCj9HlNM7P8sqSKwuIdc oyjI2Hqs+LzmzE4ZsfboEEuo2RbJ61T19N7MeNKuzLYWxdmx4+jSLl0Czl1ogjxD 0pmko3xxXvN1jMxFUm8tpfas+u2k6euX2xlvFnUBSSs5GB1f28uwSkE7BC1zIKsY yINMlgPva6kz9vRL1cO4IZCODcMLpipnJKn3HXRJNeA1x5PXByLJyHbiH/bfTtI= =dhYK -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
