Separate hashing function when responding to caching requests

[alexander-camuto]

• Currently providers can claim they already have a CID locally when receiving a caching request. This provides a vector of attack whereby malicious providers could lie about the content they have locally to intentionally reduce the replication factor / redundancy of specific pieces of content.

• A simple solution to this is for the provider to back up this claim using a new hash of the content DAG (eg. keccak / sha-3) that the CID alone wouldn't provide -- serving as a simple proof that the provider does have the content.

  • the problem is that the provider can hold content, hash it, and subsequently delete it, but store the hash to respond to subsequent requests.
  • a potential solution is to use a keyed hash function, whereby a node sending caching requests also includes a randomly generated key as a payload. The nodes responding then have to hash the DAG using that key, providing a proof that, at least at that given point in time, they did actually hold the content.

[tchardin]

Note: the method should rehash each block of the specified DAG with the key.