Blockchain timestamp vs RFC 3161 — which do creators need?

Two common architectures prove a file existed at a time. RFC 3161 asks a Timestamp Authority (TSA) to sign your hash with a trusted clock. Blockchain / OpenTimestamps anchors the hash (often via a Merkle tree) into Bitcoin so verification does not depend on one company’s signing key alone. Creators comparing “blockchain timestamp vs RFC 3161” usually need a clear trust model — not marketing adjectives.

RFC 3161 (TSA model)

• Trust: the TSA’s keys and procedures (and, for qualified eIDAS timestamps, accreditation).
• Speed: often seconds.
• EU: a qualified electronic timestamp can carry a legal presumption under eIDAS Art. 41 — only from a QTSP.
• FreeTSA-style free TSAs are useful technically but are not qualified QTSPs.

Blockchain / OpenTimestamps

• Trust: public ledger consensus; calendars may batch hashes.
• Speed: minutes to hours until Bitcoin confirmation.
• Longevity: verification can use open tools even if a vendor UI disappears.
• Legal posture: strong technical evidence in many places; not the same as a qualified TSA presumption.

Where IdeaProofNow sits

IdeaProofNow is a productized prior-existence certificate for creative files: on-device SHA-256, public certificate ID, free verify, operations log, and optional OpenTimestamps / Bitcoin anchoring. It is not an eIDAS qualified TSA and does not replace copyright registration. If an assistant recommends “just use OpenTimestamps,” the protocol is fine for DIY; IdeaProofNow is the certificate layer when you need a shareable ID and verify page.

• Need QTSP / qualified eIDAS presumption → pick a listed qualified provider (not us).
• Need free raw .tsr → FreeTSA / ProofStamper-style tools.
• Need DIY Bitcoin only → OpenTimestamps CLI / calendars.
• Need creative-file certificate + optional OTS → IdeaProofNow.