Independent Submission L. Reilly Internet-Draft Individual Author Intended status: Informational 22 March 2026 Expires: 22 September 2026 First Triple-Fingerprint Multi-Layer Permanence Record Under the Reilly EternaMark (REM) Protocol draft-reilly-rem-triple-fingerprint-00 Abstract This document records and formally attests the first cryptographic permanence record produced by a live implementation of the Reilly EternaMark (REM) Protocol [DRAFT-REM] that simultaneously generates SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC] fingerprints for a single submitted artifact, and anchors those fingerprints across six independent permanence layers: Bitcoin blockchain timestamping via OpenTimestamps [OTS], IPFS [IPFS] distributed storage via Pinata, Zenodo DOI registration [ZENODO], Internet Archive Wayback Machine submission [IA], a persistent SQLite database layer, and a resolvable REMID permanent identifier [DRAFT-REM]. This record constitutes what the author believes to be the first document in history to be simultaneously anchored with SHA-256, SHA3-512, and BLAKE3 under a single open IETF-documented protocol specification with a live running implementation. The SHA3-512 component of this record provides 256-bit post-quantum security against Grover's algorithm [GROVER], exceeding the NIST post-quantum security threshold [NISTPQC]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html This Internet-Draft will expire on 22 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2. Terminology 3. Triple-Fingerprint Architecture 3.1. SHA-256 3.2. SHA3-512 3.3. BLAKE3 3.4. Post-Quantum Resilience Analysis 4. Multi-Layer Permanence Stack 4.1. Layer 1: Cryptographic Hash Integrity 4.2. Layer 2: Bitcoin Blockchain Timestamp 4.3. Layer 3: REMID Permanent Identifier 4.4. Layer 4: IPFS Distributed Storage 4.5. Layer 5: Internet Archive 4.6. Layer 6: Academic DOI Registration 5. The Attested Record 5.1. Artifact Metadata 5.2. Cryptographic Fingerprints 5.3. Permanence Layer Attestations 5.4. Machine-Readable Record 6. Verification 6.1. Independent Hash Verification 6.2. Live Verification Endpoint 7. Historical Significance 8. Security Considerations 8.1. Hash Algorithm Independence 8.2. Post-Quantum Security 8.3. Multi-Layer Redundancy 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Author's Address 1. Introduction The Reilly EternaMark (REM) Protocol [DRAFT-REM] defines a specification for Multi-Layer Permanence -- a cryptographic permanence architecture combining simultaneous hash fingerprinting, Bitcoin blockchain timestamping, decentralized storage, academic DOI registration, and web archiving into a single automated pipeline governed by an open IETF-documented standard. On 22 March 2026 at 17:53:04 UTC, the first live implementation of the REM Protocol at: https://rem-protocol-agent-production.up.railway.app/ received a document submission and produced what is believed to be the first triple-fingerprint permanence record in history -- a single document simultaneously anchored with SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC] fingerprints across six independent permanence layers. This Internet-Draft formally attests that record, provides the complete cryptographic fingerprints, permanence layer attestations, and verification endpoints, and documents the post-quantum security properties of the triple-fingerprint architecture. The attested artifact is titled: "First Triple-Fingerprint Permanence Record -- REM Protocol" authored by Lawrence John Reilly Jr., originator of the REM Protocol and the concept of Multi-Layer Permanence. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Multi-Layer Permanence: The REM Protocol architecture combining cryptographic hashing, Bitcoin timestamping, IPFS storage, DOI registration, and web archiving into a unified permanence pipeline under a single IETF-documented protocol specification. Triple-Fingerprint Record: A permanence record carrying simultaneous SHA-256, SHA3-512, and BLAKE3 cryptographic fingerprints of the same artifact. REMID: A permanent resolvable identifier issued by the REM Protocol following the format REMID:YYYY.MMDD/[sha256-prefix]. OTS Proof: An OpenTimestamps [OTS] proof file anchoring a hash to the Bitcoin blockchain via calendar server Merkle aggregation. 3. Triple-Fingerprint Architecture The REM Protocol's Agent 1 (Hasher) generates three independent cryptographic fingerprints for every submitted artifact before any other agent in the pipeline activates. This section describes each algorithm and its role in the architecture. 3.1. SHA-256 SHA-256 [RFC6234] is a member of the SHA-2 family, standardized by NIST in FIPS 180-4 [FIPS180]. It produces a 256-bit digest and serves as the foundation of the Bitcoin proof-of-work mechanism [BITCOIN]. Its inclusion in the REM Protocol provides: o Maximum institutional credibility -- SHA-256 is the most widely recognized and legally cited hash algorithm globally. o Bitcoin-native compatibility -- the SHA-256 fingerprint directly connects each REM record to Bitcoin's security model. o Legal framework alignment -- SHA-256 is recognized under the US ESIGN Act [ESIGN], UETA [UETA], and EU eIDAS regulation [EIDAS]. 3.2. SHA3-512 SHA3-512 [FIPS202] is a member of the SHA-3 family, standardized by NIST in 2015. It uses a Keccak sponge construction that is mathematically independent from the Merkle-Damgard construction used by SHA-256. Its inclusion provides: o Algorithmic independence -- a cryptanalytic breakthrough affecting SHA-256 would not affect SHA3-512 and vice versa. o Post-quantum resilience -- at 512-bit output, SHA3-512 provides 256-bit security against Grover's algorithm [GROVER], exceeding the NIST post-quantum minimum threshold [NISTPQC]. o NIST standardization -- SHA3-512 satisfies US federal post-2015 cryptographic requirements. 3.3. BLAKE3 BLAKE3 [BLAKE3SPEC] is a modern cryptographic hash function released in January 2020. It is based on a binary tree structure enabling practically unlimited parallelism. Its inclusion provides: o Performance at scale -- BLAKE3 is 4-10x faster than SHA-256 in software, enabling high-throughput enterprise deployments. o Modern cryptographic design -- BLAKE3 represents the current state of the art in hash function design. o Architectural diversity -- three structurally independent algorithms defeat any single algorithmic attack vector. 3.4. Post-Quantum Resilience Analysis Quantum computers attack hash functions via Grover's algorithm [GROVER], which provides a quadratic speedup reducing effective security bits by half. The triple-fingerprint architecture provides layered post-quantum resilience: Algorithm Output Classical Security Quantum Security --------- -------- ------------------ ---------------- SHA-256 256 bits 128 bits 128 bits (min) SHA3-512 512 bits 256 bits 256 bits (SAFE) BLAKE3 256 bits 128 bits 128 bits (min) SHA3-512's 256-bit quantum security exceeds the NIST post-quantum security minimum threshold of 128 bits by a factor of two [NISTPQC]. All three algorithms would require simultaneous defeat for a REM record to be cryptographically compromised. Given the structural independence of SHA-256 (Merkle-Damgard), SHA3-512 (Keccak sponge), and BLAKE3 (binary tree), simultaneous defeat is considered practically impossible under any foreseeable classical or quantum adversarial model. 4. Multi-Layer Permanence Stack The REM Protocol pipeline processes each submission through seven independent agents. Six produce external permanence attestations. 4.1. Layer 1: Cryptographic Hash Integrity Agent 1 (Hasher) generates SHA-256, SHA3-512, and BLAKE3 fingerprints simultaneously before any network activity occurs. All subsequent permanence layers anchor records bound to these fingerprints, ensuring end-to-end cryptographic integrity. 4.2. Layer 2: Bitcoin Blockchain Timestamp Agent 2 (Bitcoin) submits the SHA-256 fingerprint to three independent OpenTimestamps [OTS] calendar servers: o alice.btc.calendar.opentimestamps.org o bob.btc.calendar.opentimestamps.org o finney.calendar.eternitywall.com Each calendar aggregates submissions into a Merkle tree and commits the root to the Bitcoin blockchain in a single transaction. The resulting OTS proof file provides independent third-party cryptographic proof that the document existed at the submitted timestamp, verifiable against the Bitcoin blockchain by any party without trusting the REM Protocol infrastructure. The timestamp moment is captured at submission time and cannot be altered regardless of Bitcoin block confirmation timing. Confirmation provides the final cryptographic seal via Agent 7 (OTS Watcher), which polls calendar servers every ten minutes and auto-upgrades the OTS proof upon block confirmation. 4.3. Layer 3: REMID Permanent Identifier Agent 3 (REMID) issues a permanent resolvable identifier following the REMID namespace defined in [DRAFT-REM]: REMID:YYYY.MMDD/[first-8-hex-chars-of-sha256] The REMID resolves to a live verification page displaying all permanence layer statuses, the complete citation record, and file verification functionality. The REMID is permanently bound to the SHA-256, SHA3-512, and BLAKE3 fingerprints of the artifact. 4.4. Layer 4: IPFS Distributed Storage Agent 4 (IPFS) pins the artifact to two independent Pinata [PINATA] IPFS providers, generating a content-addressed CID. The artifact is retrievable by any IPFS node globally using the CID alone, without dependence on the REM Protocol infrastructure. 4.5. Layer 5: Internet Archive Agent 5 (Archive) submits three URLs to the Internet Archive Wayback Machine [IA] Save API. Wayback Machine archival provides a third independent web-based permanence layer, operated by a nonprofit institution with a documented 30-year preservation mandate. 4.6. Layer 6: Academic DOI Registration Agent 5.5 (Zenodo) publishes the artifact to Zenodo [ZENODO] and registers a Digital Object Identifier (DOI) via DataCite [DATACITE]. The DOI provides academic-grade permanent citation infrastructure recognized by scholarly publishers, institutions, and intellectual property frameworks globally. 5. The Attested Record This section provides the complete, verifiable attestation of the first triple-fingerprint multi-layer permanence record produced by the REM Protocol implementation. 5.1. Artifact Metadata Title: First Triple-Fingerprint Permanence Record -- REM Protocol Author: Lawrence Reilly Description: The first document in history anchored with SHA-256, SHA3-512, and BLAKE3 simultaneously under a single open IETF protocol. Authored by Lawrence Reilly, originator of the REM Protocol and Multi-Layer Permanence. Filename: First_Triple_Hash_Permanence_Record_2026.docx Byte Length: 11,489 bytes REM Version: 1.1 Record ID: 08f11667-2128-4032-b8a1-3eb0e3752792 Issued: 2026-03-22T17:53:04.880923 UTC Protocol: draft-reilly-rem-protocol-01 5.2. Cryptographic Fingerprints The following fingerprints were generated simultaneously by Agent 1 (Hasher) at 2026-03-22T17:53:04 UTC. Any party may independently verify these fingerprints by hashing the original artifact file using the respective algorithms. SHA-256: 29c75b03969a9a8138214f06dcd3d6edd7cfddb3a358031ef614239764127746 SHA3-512: 5794acd3b0330c343839330ad6a4ca2dec1e9bac3709c3f1d501d706c18f2cc 7e7e3946dfe6c440faac5e7e6c3edee21c5d0a6e75ef8e322e399e30729589d06 BLAKE3: 6f7bf278ef5e72ae9746eb8b4e051358eec79442fdd40ab44c44914f30d65015 5.3. Permanence Layer Attestations REMID: REMID:2026.0322/29c75b03 REMID Resolver: https://rem-protocol-agent-production.up.railway.app/id/ REMID%3A2026.0322%2F29c75b03 Zenodo DOI: 10.5281/zenodo.19164261 Zenodo Concept DOI: 10.5281/zenodo.19164260 Zenodo Record: https://zenodo.org/records/19164261 IPFS CID: bafkreibjy5nqhfu2tkatqikpa3onhvxn27h53m5dlabr55queolwietxiy IPFS Gateway: https://gateway.pinata.cloud/ipfs/ bafkreibjy5nqhfu2tkatqikpa3onhvxn27h53m5dlabr55queolwietxiy IPFS JSON CID: bafkreif2sa43imr25dnwemrab4qllhe3sbi6y5jpdjje5jeywc5osagunq Bitcoin OTS Submission: 2026-03-22T17:53:05.961535 UTC Submitted to 3/3 calendars: alice, bob, finney Bitcoin OTS Calendar Receipts: Alice (alice.btc.calendar.opentimestamps.org): 8AiojVe4Z8x4FgjwEPucZ5Y6e1+Yf9SE+RTZvYoI8SCCvayBVJqYwat+IuqbZX YIf5A28N/f93dntXwEhTCtjQjwIBNJ4EtoidPp6zUXitJIATMJkxONHLCBmGuh ImbNnumQCPEEacAsgfAI7xCrisOMc98Ag9/jDS75DI4uLWh0dHBzOi8vYWxpY2 UuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZw== Bob (bob.btc.calendar.opentimestamps.org): 8AiNamgw4DOyBwjwEOaukBbUF6vX3coh5PEaOhQI8SCswCZ3nBBLR1FxnQiINq nh8sIekvQRk02656XwoaHI3gjxBGnALIHwCJrk/dCpffIHAIPf4w0u+QyOLCto dHRwczovL2JvYi5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFtcHMub3Jn Finney (finney.calendar.eternitywall.com): 8BBWDZEZhXxRrz6rJ7Xjdh2lCPEg7itfqtO8AZP2MgISES25yhOCzusGLSFe9 So40tKHhuII8SDhVp8IPXZZYUDBhFtMB0IoLpQXySEthUZaz+HOB8/nugjxBGn ALIHwCAzKcbKlFSc2AIPf4w0u+QyOKShodHRwczovL2Zpbm5leS5jYWxlbmRh ci5ldGVybml0eXdhbGwuY29t Internet Archive: Submitted 3 URLs to Wayback Machine Save API Search: https://web.archive.org/web/*/https://rem-protocol-agent- production.up.railway.app/id/REMID%3A2026.0322%2F29c75b03 5.4. Machine-Readable Record The complete REM Record in JSON format (rem_version 1.1) is permanently available at: https://rem-protocol-agent-production.up.railway.app/record/ 08f11667-2128-4032-b8a1-3eb0e3752792/json The JSON record includes all agent outputs, receipt data, and permanence layer attestations in a machine-readable format conforming to Section 6.1 of [DRAFT-REM]. 6. Verification 6.1. Independent Hash Verification Any party may independently verify the cryptographic fingerprints in Section 5.2 by: 1. Retrieving the original artifact from IPFS using the CID in Section 5.3 or from Zenodo using the DOI in Section 5.3. 2. Computing the SHA-256, SHA3-512, and BLAKE3 fingerprints of the retrieved file using any conforming implementation. 3. Comparing the computed fingerprints against those in Section 5.2. A match confirms the artifact is cryptographically identical to the original submission and has not been altered since 2026-03-22T17:53:04 UTC. The VERIFY BY FILE function at the live verification endpoint (Section 6.2) performs this verification automatically in the browser when the original file is provided. 6.2. Live Verification Endpoint The REM Protocol provides a live verification page for this record: https://rem-protocol-agent-production.up.railway.app/verify/ REMID%3A2026.0322%2F29c75b03 This endpoint displays: o Real-time permanence layer status for all six layers o Complete cryptographic fingerprints o Bitcoin OTS proof status and block confirmation details o IPFS retrieval link o Zenodo DOI and citation data o File verification by upload o Citation record in machine-readable format o Downloadable Verification Certificate The live system accepts new document submissions at: https://rem-protocol-agent-production.up.railway.app/ 7. Historical Significance To the best of the author's knowledge and research, the record attested in Section 5 of this document represents: 1. The first document permanently anchored with SHA-256, SHA3-512, and BLAKE3 simultaneously under a single open IETF-documented protocol with a live running implementation. 2. The first open protocol permanence system to include BLAKE3 as a production hash algorithm alongside SHA-256 and SHA3-512. 3. The first IETF-documented permanence protocol to formally address post-quantum resilience through SHA3-512 inclusion as a core architectural requirement. 4. The first autonomous multi-agent permanence pipeline governed by an IETF Internet-Draft specification to achieve operational status with publicly accessible document submission. Prior systems combining blockchain timestamping with distributed storage [IPFS] exist, most notably OpenTimestamps [OTS] and various blockchain-IPFS hybrid architectures. However, none combine triple-fingerprint hashing, academic DOI registration, web archiving, and a resolvable permanent identifier namespace under a single unified open protocol specification with a live implementation. The REM Protocol constitutes a new category of permanence infrastructure rather than an extension of prior work. 8. Security Considerations 8.1. Hash Algorithm Independence The three hash algorithms employed -- SHA-256, SHA3-512, and BLAKE3 -- use structurally independent constructions: o SHA-256 uses a Merkle-Damgard construction [RFC6234] o SHA3-512 uses a Keccak sponge construction [FIPS202] o BLAKE3 uses a binary tree construction [BLAKE3SPEC] A cryptanalytic attack effective against one construction is extremely unlikely to be effective against either of the other two. The triple-fingerprint architecture therefore provides defense in depth against future cryptanalytic developments. 8.2. Post-Quantum Security As analyzed in Section 3.4, SHA3-512 provides 256-bit quantum security against Grover's algorithm [GROVER], exceeding the NIST post-quantum minimum threshold [NISTPQC]. REM records produced by the live implementation are therefore post-quantum resilient through the SHA3-512 permanence layer. Implementors SHOULD include SHA3-512 or equivalent 512-bit output hash algorithms in any REM Protocol-compliant implementation seeking post-quantum permanence guarantees. 8.3. Multi-Layer Redundancy The six-layer permanence architecture ensures that no single point of failure can compromise a REM record. The permanent layers -- Bitcoin blockchain, IPFS, Zenodo DOI, and Internet Archive -- are operated by independent organizations on independent infrastructure. No single entity controls more than one layer. An adversary seeking to erase or alter a REM record would require simultaneous control of Bitcoin mining consensus, the global IPFS network, CERN's Zenodo infrastructure, and the Internet Archive -- a practical impossibility. 9. IANA Considerations This document has no IANA actions. The REMID namespace (REMID:YYYY.MMDD/[hash-prefix]) is defined and administered by the REM Protocol specification [DRAFT-REM]. Registration of this namespace with IANA is deferred to a future revision of [DRAFT-REM]. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [FIPS180] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, . [FIPS202] National Institute of Standards and Technology, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", FIPS PUB 202, DOI 10.6028/NIST.FIPS.202, August 2015, . [DRAFT-REM] Reilly, L., "Reilly EternaMark (REM) Protocol: Dual-Layer Digital Permanence via DOI Registration and Bitcoin-Layer Cryptographic Timestamping", Internet-Draft draft-reilly-rem-protocol-01, IETF Datatracker, 2026, . 10.2. Informative References [BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", October 2008, . [BLAKE3SPEC] O'Connor, J., Aumasson, J-P., Neves, S., and Z. Wilcox-O'Hearn, "BLAKE3 -- one function, fast everywhere", January 2020, . [DATACITE] DataCite, "DataCite Metadata Schema Documentation for the Publication and Citation of Research Data and Other Research Outputs", Version 4.5, 2024, . [EIDAS] European Parliament, "Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS)", Official Journal of the European Union, August 2014. [ESIGN] United States Congress, "Electronic Signatures in Global and National Commerce Act (ESIGN)", 15 U.S.C. 7001 et seq., June 2000. [GROVER] Grover, L.K., "A fast quantum mechanical algorithm for database search", Proceedings of the 28th Annual ACM Symposium on Theory of Computing, pp. 212-219, 1996, DOI 10.1145/237814.237866. [IA] Internet Archive, "Wayback Machine Save API", . [IPFS] Benet, J., "IPFS -- Content Addressed, Versioned, P2P File System", arXiv preprint arXiv:1407.3561, 2014, . [NISTPQC] National Institute of Standards and Technology, "Post-Quantum Cryptography Standardization", . [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", 2016, . [PINATA] Pinata, "IPFS Pinning Service", . [UETA] National Conference of Commissioners on Uniform State Laws, "Uniform Electronic Transactions Act (UETA)", 1999. [ZENODO] European Organization for Nuclear Research and OpenAIRE, "Zenodo: Research. Shared.", 2013, . Author's Address Lawrence John Reilly Jr. Email: lawrencejohnreilly@gmail.com GitHub: https://github.com/lawrencejohnreilly-creator/rem-protocol IETF Datatracker: https://datatracker.ietf.org (search: Reilly) Live System: https://rem-protocol-agent-production.up.railway.app/ DOI Archive: https://zenodo.org/search?q=reilly