Is IPNS susceptible to replay attacks?

From @se3000 on Wed Nov 04 2015 15:29:44 GMT+0000 (UTC)

The way I understand it, IPNS is addressed by the hash of a node’s public key.

I’m imagining some kind of valuable dynamic information being served over IPNS, and a malicious party who prefers an old version to a new version could intentionally choose to serve the old one instead of updating. Is that a possibility?

It seems like this risk can be mitigated by checking with more peers. I’m wondering if there’s any way to resolve the dispute, like time stamping… Or is there something I’m missing, and this isn’t actually a risk?

Copied from original issue:

From @whyrusleeping on Wed Nov 04 2015 17:30:50 GMT+0000 (UTC)

What i describe here is the current implementation of IPNS, a more flexible implementation will come a little later.

Each record is tagged with a monotonically incrementing sequence number and an ‘end of life’ timestamp, and the entire record is signed. When resolving ipns records, the requesting node will fetch a good number of them (currently 16) from the dht. Once these records are gathered, any with invalid signatures are thrown out. Next, any with expired timestamps are thrown out. The sequence numbers of each remaining record are then compared, and the highest one is selected. Any node who sent the requester an ‘older’ or ‘invalid’ record will have the latest record sent to them by the requester as a network correction.

While this isnt a guarantee that replay attacks are completely impossible, it does make it difficult to pull off.

From @jbenet on Thu Nov 05 2015 07:32:42 GMT+0000 (UTC)

cryptographic freshness, TTLs, and update commitments are all ways of dealing with this that will be supported by IPRS (what IPNS will soon layer over) – see

From @wigy-opensource-developer on Wed Oct 26 2016 14:00:37 GMT+0000 (UTC)

@jbenet Hi! I know you are in a great refactoring related to GitHub organizations… Could you please point me to the new place of this broken link?

The closest I could find was , but that also referred to the broken spec.

From @dignifiedquire on Wed Oct 26 2016 14:02:55 GMT+0000 (UTC)

@wigy-opensource-developer I think this is what you are looking for

From @wigy-opensource-developer on Wed Oct 26 2016 14:05:58 GMT+0000 (UTC)

Wow, that was fast. Thanks!


While I think that the generation count is enough to solve problems with replay attacks, it would be awsome if the IPNS entry also included a ‘prev’ link as well. That way you could see the whole history of the IPNS entry by following the dag down the ‘prev’ links. Will this ever be possible? I think that would make validation much stronger, and it would also be an interesting “wayback machine” like feature in its own right.

ipns/entryabc -> ipfs/efg

generation: 5
prev: ipfs/hij

generation 4
prev: ipfs/klm

generation 3

generation 2
prev: ipfs/qrs

generation 1
prev: nil