quoting myself, bittorrent is like the Hegel of
#P2P, it is the simplest protocol i am aware of that is quite literally just the core of the idea as a spec and then decades of history, culture, and practice crusted on top of it. hashes of chunks of data overlaid on top of the data itself to facilitate sharing it. that's it. i am a peer. i have heard of some data via its hash. i ask around for that data. i get it and check it against the hash. end of algorithm. Yes yes, choking algorithms, trackers, transport protocols, holepunching, but that's implementation details.
You can't think about P2P without taking some implicit or explicit disposition towards bittorrent because it's such a pure expression of the idea. An analogous argument is that you can't really implement a P2P protocol without accidentally making it in some way (maybe through a few steps) compatible with bittorrent. v2 makes that bar almost zero by just being literally a set of per-file merkle trees. you can just ignore the .torrent file entirely and deal with the trees directly, all you need to do is understand when someone asks for hashes at a specific level of the tree.
If i was designing a P2P protocol, which i always am in some part of my being, I would start from bittorrent v2 and branch out from there. Being able to talk to a bittorrent client is so trivial it's almost an afterthought, an afternoon of writing udp packing and unpacking functions. If you ignore the rest of the lessons like the obvious UX affordance of having a thing to trade around like .torrent files, magnet links which are an identifier and a non-definitive starting point for resolving it, trackers which are a means of coordinating the swarm, you're just throwing away an entire generation of practical experience
