BitTorrent | Computer Networks Project

First, you need to change add the field named "orders" in Coin document.

It's like 2+2 that people will continue building up more advanced computers.

The primary cause for collision attacks is weaknesses in the hash function. Faster computers only provide very modest improvements as for every additional bit you to twice as much compute power. Even the still quite hypothetical general purpose quantum computers would only cut down collision resistance from N/2 to N/3.

Also, collision attacks are not a major threat to bittorrent. They could break certificate based systems built on top of bittorrent, e.g. where some 3rd entity vouches for the correctness of content described by a hash. But the primary use of hashes in bittorrent (integrity, i.e. getting bit-exact copies of whatever the initial seed published) is only vulnerable to preimage attacks.

and looking into new protocol, we can already see that its adoption is happening very slowly, it wouldn't be nicest thing if say in 2030 new collision occured, then developers will have to change this protocol again?

Bittorrent v2 specifies a meta version field in the info dictionary and requires that clients check for compatibility first before attempting to use the torrent, this will make future upgrades smaller and easier to roll out. But they are not specified in advance since we don't know which hashes or other security-related changes will be needed in the future. Specifying and negotiating more than one supported cryptographic primitive tends to be error-prone and increases implementation complexity.

The v2 magnet link already provides flexibility by adopting the multihash format.

V1 DHT is not compatible with V2 anyway.

That is incorrect.

The reason was very simple, and I should have understood it immediately. Power saving mode was enabled in the OS, which reduced the clock frequency of the CPU under low load. The moral is, always disable power saving when benchmarking!

Do they need to be honest and cooperate

More or less, yes.

or can the tracker somehow enforce the correct data?

Not in the general case of multiple colluding peers. In special cases of a single/few selfish downloaders it may be possible to detect them by cross-checking statistics from multiple peers but this is fragile and will require some fine-tuned heuristics to minimize false positives while still getting decent true positives.

It's basically a kludge, not something the protocol is designed for.

For the downloaded statistic a tracker could also participate in a swarm as a bittorrent peer and see the progress of a client based on have messages, but that doesn't work for upload and isn't all that reliable either because there's no guarantee that it could connect to all peers in a swarm to observe them.

The specification does not mandate if and when seeds may disconnect other seeds, although it acknowledges the behavior and allows seeds to include recently seen seeds in its PEX list which should allow downloaders to discover more seeds. The exact timing of disconnects is largely up to implementations.

Sort based on:

• Whether the item starts with a number
• Then, based on the number of characters in the leading number
• Then, do a natural sort

Note that the official specification lists that parameter as optional, meaning that it is not part of the identity of the client. Rather it should be considered as a hint to the tracker that the tracker should hand out that IP to other clients instead of the source of the announce connection. This hint should be ignored if the tracker doesn't trust the client.

Trust can be established if a client authenticates itself to the tracker (e.g. via HTTP basic auth or a secret token in the announce URL).

Instead of trusting the client the tracker could also verify it, e.g. by opening a bittorrent connect to the IP and port that was announced and then send a bittorrent handshake for the infohash that was announced to check if the remote can accept bittorrent connections. That also has the advantage of rejecting announces that aren't reachable due to firewalls or NAT limitations.

For open, public trackers neither approach is practical, so they usually ignore the &ip=... parameter. Trackers deployed in more restricted environments do make use of the trust and/or verify approaches.

Bittorrent is designed for random access to keep data available via the rarest-first strategy. See Section 2.4.2 of the bittorrent econ paper. While it is possible to operate it in a streaming manner anyway this generally isn't recommended and certainly shouldn't be the default, otherwise performance could severely degrade for all swarm members or content could even become unavailable.

Not long after asking this question, it occurred to me that I might not need express at all. It turns out that was correct.

For anyone wanting a Heroku-ready bittorrent-tracker, here is the updated code: