shafemtol on Nostr: > Including a recent block hash is a proof of absence, meaning that the note cannot ...
> Including a recent block hash is a proof of absence, meaning that the note cannot have been created before that block was mined. It proofs the lower bound, that the message is older than that block. The attacker can include a very old blockhash years after it was mined.
I think you're missing the idea here. The point is exactly to prove that a note's id was created after a certain block was mined. But the block is not chosen by the attacker. It must match a set of recent blocks by the filtering client. The client is only interested in recent notes, not historical ones. By using a filter as provided in the example, the client is guaranteed (by the promised behavior of any relay that follows NIP-01 + NIP-12) that any notes returned were created after the list of block hashes chosen by the client.
Proof of freshness does not solve the case where an attacker concentrates PoW on creating notes targeting a very old block hash. For that case, you can combine this NIP with an opentimestamps proof as you mentioned.
https://github.com/nostr-protocol/nips/pull/296#issuecomment-1443568647
I think you're missing the idea here. The point is exactly to prove that a note's id was created after a certain block was mined. But the block is not chosen by the attacker. It must match a set of recent blocks by the filtering client. The client is only interested in recent notes, not historical ones. By using a filter as provided in the example, the client is guaranteed (by the promised behavior of any relay that follows NIP-01 + NIP-12) that any notes returned were created after the list of block hashes chosen by the client.
Proof of freshness does not solve the case where an attacker concentrates PoW on creating notes targeting a very old block hash. For that case, you can combine this NIP with an opentimestamps proof as you mentioned.
https://github.com/nostr-protocol/nips/pull/296#issuecomment-1443568647