Network Working Group L. Reilly Internet-Draft REM Technologies & Consulting, LLC Intended status: Informational 24 August 2026 Expires: 25 February 2027 The Triple-Fingerprint Permanence Chain and the First Attested Triple-Fingerprint Record Under the Reilly EternaMark (REM) Protocol draft-reilly-rem-triple-fingerprint-01 Abstract This document specifies the Triple-Fingerprint Permanence Chain, a hash-linked record chain in which every link is computed independently under SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC], and in which each link commits to all three predecessor links so that the three chains are entangled rather than parallel. A verifier that checks all three link algorithms must be defeated by simultaneous collisions in three structurally distinct hash constructions on the same input. This document also re-attests, with corrections, the genesis record of that chain: the permanence record produced on 22 March 2026 by a live implementation of the Reilly EternaMark (REM) Protocol [DRAFT-REM-02], carrying simultaneous SHA-256, SHA3-512, and BLAKE3 fingerprints of a single artifact anchored across Bitcoin timestamping via OpenTimestamps [OTS], IPFS [IPFS], Zenodo DOI registration [ZENODO], the Internet Archive Wayback Machine [IA], a persistent database layer, and a resolvable REMID identifier. This revision supersedes draft-reilly-rem-triple-fingerprint-00 and corrects three defects in it. First, -00 published the Bitcoin layer's OpenTimestamps receipts as evidence of blockchain anchoring when those receipts were pending calendar commitments carrying no Bitcoin attestation. Second, -00's post-quantum analysis applied Grover's algorithm [GROVER] to preimage resistance while the security property that actually binds a permanence record is collision resistance, which Grover does not meaningfully reduce. Third, -00 asserted that combining three hash algorithms multiplies security; by the multicollision result of [JOUX], the collision resistance of such a combination is bounded near that of its strongest member rather than the sum of its members. The value of the combination is algorithmic hedging, which is a different and more defensible claim. Precedence claims made in -00 are narrowed to scoped, falsifiable statements and are accompanied by an expanded treatment of prior art, in particular the Evidence Record Syntax [RFC4998]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 25 February 2027. 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to -00 . . . . . . . . . . . . . . . . . . 4 1.2. Implementation Status . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . 7 3. Triple-Fingerprint Architecture . . . . . . . . . . . . . . 9 3.1. SHA-256 . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. SHA3-512 . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. BLAKE3 . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Security Properties of the Combination . . . . . . . . 12 3.4.1. Which Property Binds a Permanence Record . . . . . 12 3.4.2. Classical and Quantum Security . . . . . . . . . . 13 3.4.3. Hedging, Not Addition . . . . . . . . . . . . . . . 15 3.4.4. Corrected Post-Quantum Statement . . . . . . . . . 16 4. The Triple-Fingerprint Permanence Chain . . . . . . . . . . 18 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Record Commitment . . . . . . . . . . . . . . . . . . . 19 4.3. Link Construction and Entanglement . . . . . . . . . . 21 4.4. The Braid . . . . . . . . . . . . . . . . . . . . . . . 22 4.5. Genesis . . . . . . . . . . . . . . . . . . . . . . . . 23 4.6. Chain Verification . . . . . . . . . . . . . . . . . . 24 4.7. Security Analysis . . . . . . . . . . . . . . . . . . . 26 4.8. Algorithm Retirement Without Chain Rewrite . . . . . . 28 5. Multi-Layer Permanence Stack . . . . . . . . . . . . . . . 30 5.1. Layer Classification . . . . . . . . . . . . . . . . . 30 5.2. Layer 1: Hash Integrity . . . . . . . . . . . . . . . . 32 5.3. Layer 2: Bitcoin Timestamping . . . . . . . . . . . . . 32 5.4. Layer 3: REMID Identifier . . . . . . . . . . . . . . . 35 5.5. Layer 4: IPFS . . . . . . . . . . . . . . . . . . . . . 36 5.6. Layer 5: Web Archiving . . . . . . . . . . . . . . . . 37 5.7. Layer 6: DOI Registration . . . . . . . . . . . . . . . 38 5.8. What Each Layer Does and Does Not Guarantee . . . . . . 39 6. The Attested Genesis Record . . . . . . . . . . . . . . . . 41 6.1. Artifact Metadata . . . . . . . . . . . . . . . . . . . 41 6.2. Cryptographic Fingerprints . . . . . . . . . . . . . . 42 6.3. Permanence Layer Attestations . . . . . . . . . . . . . 43 6.4. Bitcoin Attestation Status . . . . . . . . . . . . . . 44 6.5. Cross-Layer Consistency Check . . . . . . . . . . . . . 47 6.6. Endpoint Migration Since -00 . . . . . . . . . . . . . 48 7. Verification . . . . . . . . . . . . . . . . . . . . . . . 50 8. Prior Art and Claims of Precedence . . . . . . . . . . . . 54 9. Security Considerations . . . . . . . . . . . . . . . . . . 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . 65 Appendix A. Changes from -00 . . . . . . . . . . . . . . . . . 70 Appendix B. Genesis Chain Test Vectors . . . . . . . . . . . . 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 77 1. Introduction The Reilly EternaMark (REM) Protocol [DRAFT-REM-02] defines Multi-Layer Permanence: a cryptographic permanence architecture combining simultaneous hash fingerprinting, Bitcoin blockchain timestamping, content-addressed storage, DOI registration, and web archiving into a single automated pipeline governed by an open specification. On 22 March 2026 at 17:53:04 UTC, a live implementation of the REM Protocol received a document submission and produced a permanence record carrying SHA-256 [RFC6234], SHA3-512 [FIPS202], and BLAKE3 [BLAKE3SPEC] fingerprints of the same artifact, anchored across six layers. Revision -00 of this document attested that record. This revision does two things. It specifies the Triple-Fingerprint Permanence Chain (Section 4), which generalizes the single record of -00 into a hash-linked sequence. Each link in the chain is computed independently under all three algorithms, and each link commits to all three predecessor links, so that the three chains are entangled rather than merely parallel. An adversary who breaks one algorithm cannot silently rewrite the chain that a verifier checks under another. This is the substantive technical addition of -01, and it is the reason the document's title has changed. It also re-attests the 22 March 2026 record as the genesis of that chain, with corrections. Revision -00 contained defects that a careful reader would find, and it is better for the author to find them first. Those defects are set out in Section 1.1 and the corrections are carried through the body of the document. The attested artifact is titled: "First Triple-Fingerprint Permanence Record -- REM Protocol" authored by Lawrence John Reilly Jr., originator of the REM Protocol and of the term Multi-Layer Permanence. 1.1. Relationship to -00 This document supersedes draft-reilly-rem-triple-fingerprint-00. Three defects in -00 are corrected here, and a fourth class of statement is narrowed. 1.1.1. Pending Attestations Presented as Bitcoin Anchors Section 5.3 of -00 published three base64 blobs under the heading "Bitcoin OTS Calendar Receipts", within a document whose Section 4.2 described a "Bitcoin Blockchain Timestamp" layer. Those blobs decode to OpenTimestamps proofs carrying the pending attestation marker. None carried a Bitcoin attestation. A pending attestation is a calendar server's undertaking to include a digest in a future Bitcoin commitment. It is not a Bitcoin timestamp, it carries no proof-of-work, and if every calendar operator were to discard its aggregation state before the next commitment, a pending receipt would resolve to nothing. Revision -00 therefore published, as the Bitcoin layer of a permanence record, three promises rather than three proofs. The underlying operation was sound; the submissions were made to three independent calendars and the record's Agent 7 was designed to upgrade them on confirmation. What was wrong was the presentation. Section 5.3 and Section 6.4 of this document distinguish the pending and attested states normatively, require that upgrade status be stated wherever an OTS receipt is published, and require that the Bitcoin block height be given once available. 1.1.2. Grover Applied to the Wrong Property Section 3.4 of -00 presented a table of "Classical Security" and "Quantum Security" values and concluded that SHA3-512 provides 256-bit post-quantum security "exceeding the NIST post-quantum security threshold". The table conflated two distinct properties. For an n-bit hash, classical collision resistance is approximately n/2 bits and classical preimage resistance is approximately n bits. Grover's algorithm [GROVER] attacks preimages, reducing preimage resistance to approximately n/2. It does not deliver a comparable reduction in collision resistance: the best known quantum collision algorithms offer at most a modest asymptotic improvement at prohibitive memory cost, and the practical quantum collision bound remains approximately the classical birthday bound. The security property that binds a permanence record is collision resistance, not preimage resistance. An adversary attacking a timestamp does not invert a digest; the adversary prepares two documents with the same digest, anchors one, and later presents the other. That is a collision attack, and specifically a chosen-prefix collision attack. The corrected consequence is favorable to the architecture but for different reasons than -00 gave. SHA-256's 128-bit collision resistance is not halved by Grover; it is already the binding figure and it survives. SHA3-512's advantage is that it offers 256-bit collision resistance, which is a real and substantial improvement. Neither fact has anything to do with the 128-bit Grover preimage figure that -00 tabulated as the quantum column. The reference to a "NIST post-quantum security threshold" was also a category error. The NIST post-quantum security categories [NISTPQC] are defined for key-establishment and signature schemes by reference to the difficulty of attacking AES and SHA-2, with Category 2 defined as being at least as hard as finding a collision in SHA-256. They are not a threshold that a hash function passes or fails. Section 3.4.4 states the corrected position. 1.1.3. Combined Security Claimed as Multiplicative Section 3.4 of -00 stated that all three algorithms "would require simultaneous defeat" and that this made compromise "practically impossible". The first clause is true of a verifier that checks all three. The implication that concatenating hash functions multiplies or sums their strength is not. [JOUX] showed that multicollisions in an iterated hash function can be found at cost only modestly above that of a single collision, with the consequence that the collision resistance of a concatenation H1(x) || H2(x) is bounded near that of the stronger component rather than the sum of the two. SHA-256 is an iterated Merkle-Damgard construction and is directly subject to that result. The correct claim, made in Section 3.4.3 and Section 4.7, is that the combination provides hedging rather than addition: its collision resistance is approximately that of its strongest member, currently the 256 bits of SHA3-512, and the contribution of the other two members is insurance against a cryptanalytic break in a specific construction rather than additional bits. That claim is weaker than -00's and is the one that will survive review. 1.1.4. Precedence Claims Narrowed Section 7 of -00 made four claims to historical priority. Claims of the form "first in history" are not falsifiable by a reader and are not the kind of assertion an Internet-Draft is well suited to carry. Section 8 of this document restates them as scoped claims about a described search, identifies the prior art the author is aware of, and states plainly what the architecture does and does not do that its predecessors did not. The most significant omission from -00 was the Evidence Record Syntax [RFC4998], which addresses long-term hash algorithm renewal directly and is the closest existing standardized work. 1.1.5. Other Corrections Minor corrections are listed in Appendix A. They include the Trust Legal Provisions license name, the obsolete Status of This Memo boilerplate, an incorrect "Independent Submission" stream designation, an internal contradiction between Sections 4.4 and 8.3 of -00 regarding independent layer operators, an unsupported assertion about the Internet Archive's preservation mandate, an agent numbering inconsistency, and the migration of every HTTP endpoint cited in -00. 1.2. Implementation Status This section is to be removed before publication as an RFC, in accordance with [RFC7942]. The genesis record attested in Section 6 was produced by a running implementation, not constructed for this document. The implementation has since been extended substantially, and the record's HTTP endpoints have moved, which is treated in Section 6.6. The chain construction of Section 4 is specified here in advance of a conformant implementation of the entangled link format. The author considers it important to say so. The genesis record's fingerprints are real and the test vectors in Appendix B are computed from them, but a reader should understand Appendix B as demonstrating that the construction is well defined and reproducible, not as evidence that a chain of many links has been operated in production under this exact format. Related hash- linked ledgers under single algorithms are in operation within the author's wider protocol suite. 2. Conventions and 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, as shown here. The symbol || denotes octet string concatenation. uint64be(n) denotes the encoding of the non-negative integer n as eight octets, most significant first. Hex encoding is lowercase throughout. Attested Timestamp: An OpenTimestamps proof that has been upgraded to include a Bitcoin attestation, binding a digest to a specific block. Contrast Pending Attestation. Braid: The 128-octet concatenation of the three link values of a chain record, in the fixed order SHA-256, SHA3-512, BLAKE3. The braid is the value a successor record commits to. See Section 4.4. Fingerprint: A cryptographic digest of an artifact under one of the three algorithms of this specification. Link: A per-algorithm chain value binding a record to its predecessor. Each chain record has three links. See Section 4.3. Multi-Layer Permanence: The REM Protocol architecture combining cryptographic hashing, Bitcoin timestamping, content-addressed storage, DOI registration, and web archiving into a unified pipeline under a single open protocol specification. Pending Attestation: An OpenTimestamps proof carrying only a calendar server's undertaking to commit a digest in a future Bitcoin transaction. A pending attestation conveys no proof-of-work and is not a Bitcoin timestamp. See Section 5.3. REMID: A permanent resolvable identifier issued by the REM Protocol in the form REMID:YYYY.MMDD/[sha256-prefix]. Triple-Fingerprint Record: A permanence record carrying simultaneous SHA-256, SHA3-512, and BLAKE3 fingerprints of the same artifact. Triple-Fingerprint Permanence Chain: A sequence of triple-fingerprint records in which each record commits to the braid of its predecessor under all three algorithms. See Section 4. 3. Triple-Fingerprint Architecture The REM Protocol's hashing agent generates three independent cryptographic fingerprints for every submitted artifact before any network activity occurs. This section describes each algorithm and then, in Section 3.4, states the security of the combination correctly. 3.1. SHA-256 SHA-256 [RFC6234] is a member of the SHA-2 family, standardized in FIPS 180-4 [FIPS180]. It produces a 256-bit digest using an iterated Merkle-Damgard construction, and underlies the Bitcoin proof-of-work mechanism [BITCOIN]. Its inclusion provides: o Bitcoin-native compatibility. OpenTimestamps commits SHA-256 digests, so the SHA-256 fingerprint is the value that actually enters the Bitcoin layer. The other two fingerprints are anchored transitively through the record commitment of Section 4.2, not directly by the calendar servers. o Content-address compatibility. The IPFS CID issued for the genesis artifact embeds its SHA-256 digest, which permits the cross-layer check demonstrated in Section 6.5. o Institutional and legal recognition. SHA-256 is the hash algorithm most widely cited in electronic transaction and evidentiary frameworks, including instruments such as [ESIGN], [UETA], and [EIDAS]. Note that those instruments concern electronic signatures and trust services generally rather than mandating any particular digest algorithm; the claim here is one of recognition and familiarity, not of compliance conferred by algorithm choice. 3.2. SHA3-512 SHA3-512 [FIPS202] is a member of the SHA-3 family, standardized in 2015. It uses a Keccak sponge construction that is structurally independent of the Merkle-Damgard construction used by SHA-256. Its inclusion provides: o Structural independence. A cryptanalytic advance against the Merkle-Damgard mode, or against the SHA-2 compression function, would not transfer to a sponge. o The highest collision resistance in the set. At 512-bit output, SHA3-512 offers approximately 256-bit collision resistance, which under Section 3.4.3 is the figure that governs the combination as a whole. o Resistance to length-extension. Sponge constructions are not subject to the length-extension property of Merkle-Damgard hashes, which matters for the link construction of Section 4.3 where a fixed-format message is hashed under all three algorithms. The domain separation prefixes specified in Section 4 address this for SHA-256; SHA3-512 does not require them for this purpose. 3.3. BLAKE3 BLAKE3 [BLAKE3SPEC] is a cryptographic hash function released in January 2020, based on a binary tree mode over a reduced-round BLAKE2 compression function. Its inclusion provides: o Throughput. BLAKE3 is substantially faster than SHA-256 in software and parallelizes across cores and SIMD lanes, which matters for an implementation fingerprinting large artifacts three times. o A third structural family. Tree hashing is distinct from both Merkle-Damgard and sponge modes. Two properties of BLAKE3 MUST be stated plainly, because -00 did not. First, BLAKE3 is an extendable-output function. Its default 256-bit output is a truncation of an arbitrarily long stream. Implementations of this specification MUST use the 256-bit default output for the fingerprint and for the link value, and MUST record the output length in the record metadata, so that a future implementation electing a longer output does not produce values that a verifier silently mismatches. Second, BLAKE3 is not standardized by NIST, the IETF, or ISO. It has received substantial cryptanalytic attention and no break is known, but it does not carry the institutional standing of the other two algorithms, and an implementation deployed into a regulated environment SHOULD NOT rely on BLAKE3 as its sole or primary fingerprint. Its role in this architecture is diversification, and diversification is exactly the role for which a younger, unstandardized function is appropriate: it is present so that a break in the standardized functions is not a break in the whole record, and its own failure would leave the record intact. 3.4. Security Properties of the Combination 3.4.1. Which Property Binds a Permanence Record A permanence record asserts that a specific artifact existed in a specific form at a specific time. The attack that defeats such an assertion is not preimage recovery. An adversary gains nothing by inverting a published digest, since the artifact is already published. The attack that defeats it is collision. The adversary prepares two artifacts, A and A', with the same digest, anchors A, and later produces A' claiming it is the anchored document. In practice this requires a chosen-prefix collision, since the two artifacts must both be meaningful documents rather than arbitrary bit strings. The history of MD5 and SHA-1 is a history of exactly this attack becoming practical. Accordingly, throughout this document the security of a fingerprint or link is stated in terms of collision resistance. Where preimage resistance is relevant it is named explicitly. 3.4.2. Classical and Quantum Security The following table replaces the table in Section 3.4 of -00. All figures are approximate security levels in bits. +-----------+--------+-------------+-------------+-------------+ | Algorithm | Output | Collision | Preimage | Preimage | | | (bits) | (classical | (classical) | (Grover) | | | | and quantum)| | | +-----------+--------+-------------+-------------+-------------+ | SHA-256 | 256 | 128 | 256 | 128 | | SHA3-512 | 512 | 256 | 512 | 256 | | BLAKE3 | 256 | 128 | 256 | 128 | +-----------+--------+-------------+-------------+-------------+ Two points follow, and they are the points -00 missed. Collision resistance appears in a single column because quantum computation does not meaningfully reduce it. Grover's algorithm [GROVER] gives a quadratic speedup for unstructured search and thus halves preimage resistance. The quantum collision algorithms of Brassard, Hoyer, and Tapp achieve an asymptotic 2^(n/3) at the cost of comparable quantum memory, and under realistic cost models that accounts for memory access the classical birthday bound of 2^(n/2) remains the operative figure. This is the position taken by NIST in the post-quantum standardization process. Therefore the quantum threat to a permanence record anchored under these algorithms is materially smaller than -00 implied by tabulating a "quantum security" column at all. The collision figures in column three are the binding ones, and they are the same before and after a cryptographically relevant quantum computer exists. 3.4.3. Hedging, Not Addition It is tempting to reason that an adversary facing three fingerprints must defeat 128 + 256 + 128 bits of security. That reasoning is wrong and this document does not rely on it. [JOUX] showed that for an iterated hash function, 2^k-way multicollisions can be constructed at cost approximately k times that of a single collision, rather than the 2^(k(n-1)/2) a random function would require. The consequence for concatenation is direct: to find a collision in H1(x) || H2(x) where H1 is iterated with n1-bit output, an adversary constructs a large multicollision set in H1 at cost near 2^(n1/2) and then searches within that set for an H2 collision. The total is bounded near the cost of attacking the stronger function alone, not the product. SHA-256 is an iterated Merkle-Damgard construction and is subject to this result directly. BLAKE3's tree mode and SHA3-512's sponge are not iterated in the same sense, and the attack does not apply to them in its original form; the author is not aware of an equivalent published result against either. Prudence nonetheless requires that the specification claim only what is defensible. This document therefore claims: o The collision resistance of the triple-fingerprint combination is approximately that of its strongest member, which is the 256 bits of SHA3-512. o The contribution of SHA-256 and BLAKE3 is hedging. If a cryptanalytic advance reduces SHA3-512 below a usable level, the record remains bound by two independent functions in two other structural families, and a verifier checking those functions is unaffected. o The combination is not claimed to provide additive bit strength, and any implementation or marketing statement derived from this specification MUST NOT make that claim. Hedging is a weaker property than addition, and it is also the property that actually motivates multi-algorithm designs in practice. Long-lived archives do not carry multiple digests because three functions are stronger than one arithmetically; they carry them because nobody can say which function will still be trusted in forty years. 3.4.4. Corrected Post-Quantum Statement The following statement replaces the post-quantum claims of -00 and SHOULD be used in preference to them wherever those claims have been repeated. A triple-fingerprint permanence record is bound by collision resistance. Its collision resistance is approximately 256 bits, furnished by SHA3-512. Grover's algorithm does not reduce this figure, because Grover attacks preimages and no comparable quantum speedup against collisions is known under realistic cost models. The record is therefore expected to remain sound against both classical and quantum adversaries for as long as 256-bit collision resistance is considered adequate, without reliance on any post-quantum signature or key-establishment scheme. This is a property of hash functions generally and is not unique to this architecture. What the architecture adds is that the failure of any one of the three functions does not end the record's bindingness. The claim in -00 that SHA3-512 "exceeds the NIST post-quantum security threshold by a factor of two" is withdrawn. The NIST categories [NISTPQC] classify key-establishment and signature schemes, defining Category 2 as at least as hard as SHA-256 collision search; they do not establish a threshold against which a hash function is measured. 4. The Triple-Fingerprint Permanence Chain 4.1. Motivation Revision -00 attested a single record. A single record proves that one artifact existed at one time. It does not order records relative to one another, and it does not make the removal of a record detectable: an implementation that issued a thousand records and later destroyed one would leave nine hundred and ninety-nine intact records, all verifying, and nothing inconsistent. Chaining solves ordering and omission together. A hash-linked chain under a single algorithm is well understood and widely deployed. What this section specifies is a chain under three algorithms simultaneously, constructed so that the three are entangled rather than parallel. The distinction matters. Three parallel chains, each computed only over its own predecessor, would be defeated one at a time: an adversary with a SHA-256 collision could rewrite the SHA-256 chain into a self-consistent alternative history, and a verifier who happened to check only SHA-256 would accept it. Entanglement means each link commits to all three predecessor links, so a rewritten SHA-256 chain cannot be made consistent with the SHA3-512 and BLAKE3 links it must incorporate without collisions in those functions as well. 4.2. Record Commitment Let a chain record at sequence number seq have: o fp256, the 32-octet SHA-256 fingerprint of the artifact o fp3, the 64-octet SHA3-512 fingerprint of the artifact o fpb3, the 32-octet BLAKE3 fingerprint of the artifact, taken at the 256-bit default output length o meta, the canonical metadata of the record The metadata MUST be serialized as UTF-8 JSON [RFC8259] conforming to I-JSON [RFC7493], with object keys sorted ascending by Unicode code point at every level of nesting, no insignificant whitespace, and no trailing newline. The metadata MUST include at minimum the record identifier, the REMID, the issuance timestamp in [RFC3339] UTC form, the REM version, and the BLAKE3 output length in bits. The metadata commitment is: H_meta = SHA3-512( 0x00 || meta ) The record commitment is: M = 0x01 || uint64be(seq) || fp256 || fp3 || fpb3 || H_meta M is a fixed-length 201-octet value: one octet of domain separation, eight of sequence number, 32 + 64 + 32 of fingerprints, and 64 of metadata commitment. Fixed length is deliberate. A variable-length commitment input hashed under three algorithms invites length-extension and ambiguity attacks against the weakest mode in the set; a fixed-length input forecloses them structurally rather than by argument. SHA3-512 is specified for H_meta rather than a shorter function because H_meta is the only variable-length input in the construction, and it is therefore the only place where a collision in the metadata encoding could substitute one record's metadata for another's. It is given the strongest available function. 4.3. Link Construction and Entanglement Let braid_prev be the 128-octet braid of the predecessor record, as defined in Section 4.4, or the genesis value of Section 4.5 when seq is 0. The three link values of the record are: L_sha256 = SHA-256 ( 0x02 || braid_prev || M ) L_sha3 = SHA3-512( 0x02 || braid_prev || M ) L_blake3 = BLAKE3 ( 0x02 || braid_prev || M ) All three are computed over the identical input. This is the entanglement: braid_prev contains the predecessor's SHA-256, SHA3-512, and BLAKE3 links, so every link of every record commits transitively to every link of every earlier record under all three algorithms. The domain separation prefixes 0x00, 0x01, and 0x02 partition the three hashing contexts of this construction, so that a metadata commitment, a record commitment, and a link value can never be confused for one another even where output lengths coincide. 4.4. The Braid The braid of a record is: braid = L_sha256 || L_sha3 || L_blake3 which is 32 + 64 + 32 = 128 octets, in that fixed order. The braid is deliberately a concatenation rather than a hash of the three links. Hashing them together under any single algorithm would make that algorithm a single point of failure for the entanglement: a break in the braid function would let an adversary substitute a braid whose components differ, defeating the property the construction exists to provide. Concatenation privileges no algorithm, at a cost of 128 octets per record, which is negligible. The chain head is the braid of the highest-numbered record. Publishing the chain head publishes all three chains at once. 4.5. Genesis For the record at seq 0: braid_prev = 128 octets of 0x00 The genesis record of the chain specified by this document is the record attested in Section 6, whose fingerprints are those published in Section 5.2 of -00 and reproduced in Section 6.2. Test vectors for its links and braid appear in Appendix B and are computed from those published fingerprints. An implementation MAY begin a chain at any record. A chain whose genesis is not the record of Section 6 MUST NOT describe itself as a continuation of the chain specified here. 4.6. Chain Verification A verifier presented with a range of chain records MUST perform the following, and a conformant verifier MUST perform step (5) for all three algorithms unless the operator has explicitly restricted it: (1) Confirm that seq values are consecutive with no gaps and no repeats across the presented range. (2) For each record, recompute H_meta from the canonical metadata and confirm it matches the recorded value. A mismatch indicates either a metadata alteration or a serialization disagreement; the verifier MUST report which canonicalization it applied. (3) For each record, reconstruct M from the sequence number, the three fingerprints, and H_meta. (4) For each record, obtain braid_prev, being the concatenation of the predecessor's three link values, or the genesis value at seq 0. (5) Recompute L_sha256, L_sha3, and L_blake3 and compare each to the recorded value. (6) Confirm that the braid of the final record matches the published chain head. (7) Where the artifact itself is available, recompute all three fingerprints from the artifact and confirm they match those in the record. A verifier that checks only one algorithm in step (5) obtains only that algorithm's assurance and MUST report which algorithm it checked. Reporting a chain as verified without naming the algorithms checked is not conformant, because the entire value of the construction lies in which functions were exercised. 4.7. Security Analysis Consider an adversary who wishes to present an alternative history: a chain that verifies but that differs from the chain actually issued, whether by altering a record, removing one, or reordering. Against a verifier checking algorithm A alone. The adversary must produce, for some record, an alternative input to A yielding the recorded L_A. Because the input includes braid_prev and M, and because both are fixed-length and fully determined by the history, this requires a collision in A. The assurance a single-algorithm verifier obtains is exactly the collision resistance of A: 128 bits for SHA-256 or BLAKE3, 256 bits for SHA3-512. Against a verifier checking all three. The adversary must produce a single alternative input that simultaneously collides under SHA-256, SHA3-512, and BLAKE3. The input is common to all three link computations, so the adversary cannot vary it per algorithm. By Section 3.4.3 the cost of this is bounded below by the cost of attacking the strongest member and is not the sum, but it is not less than attacking SHA3-512 alone, and a break confined to one construction leaves the other two intact. The practical claim, and the only one this document makes, is therefore: The chain remains binding against a verifier that checks all three algorithms for as long as at least one of the three remains collision-resistant, and the verifier can determine which of the three still holds by checking them separately and reporting the results. That is a property no single-algorithm chain has. A SHA-256 chain that outlives SHA-256's collision resistance is retroactively worthless and its holder has no remedy. A triple-fingerprint chain in the same circumstance is still verifiable under two functions, and the transition costs nothing and requires no action taken in advance. Two limits should be stated. First, entanglement protects the chain, not the artifacts. If SHA-256, SHA3-512, and BLAKE3 all remain sound but an artifact is destroyed, the chain still verifies and proves what the artifact's digests were; it does not produce the artifact. This is the integrity-versus-availability distinction of Section 5.8. Second, the chain proves relative order and completeness within itself. It does not prove that the chain operator issued a record for every event that occurred. An operator who simply declines to create a record creates no inconsistency. Chains provide tamper-evidence, not completeness; completeness requires a separate attestation over an expected population, which is outside the scope of this document. 4.8. Algorithm Retirement Without Chain Rewrite When one of the three algorithms is retired, an implementation MUST NOT recompute historical links. Recomputation would destroy the evidentiary value of the original chain and would in any case be impossible for a verifier holding only the published head. Instead: (1) The implementation publishes a Retirement Record: a normal chain record whose metadata declares the retired algorithm, the sequence number at which retirement takes effect, and the replacement algorithm if any. (2) From the effective sequence number, links continue to be computed under the remaining algorithms and, where a replacement is introduced, under the replacement. The braid length changes accordingly and the new length MUST be recorded in the Retirement Record metadata. (3) Records before the effective sequence number retain their original links, including the retired algorithm's. A verifier MAY continue to check the retired algorithm for those records and MUST report any such check as carrying only the assurance of a retired function. (4) The Retirement Record is itself linked under all algorithms in force at its own sequence number, including the retiring one. This binds the retirement decision into the chain under the algorithm being retired, at a time when that algorithm is still trusted, which is the only moment at which doing so has value. Point (4) is the substance of this section. A retirement announced after an algorithm is broken is an announcement an adversary could equally have forged. Implementations SHOULD treat the first credible published weakening of an algorithm, rather than its formal deprecation, as the trigger to issue a Retirement Record. 5. Multi-Layer Permanence Stack 5.1. Layer Classification Revision -00 presented six permanence layers as though they were interchangeable contributors to a single property. They are not. Each layer supplies one of three distinct properties, and a reader who does not distinguish them will overestimate what the architecture guarantees. Integrity layers establish that an artifact had a specific content at a specific time. They do not store the artifact. Bitcoin timestamping is an integrity layer, as is the hash fingerprinting itself. Availability layers store or serve the artifact. They do not by themselves prove anything about its history. IPFS, web archiving, and the DOI repository's file store are availability layers. Discovery layers make the record findable and resolvable. The REMID and the DOI are discovery layers. The critical asymmetry is this: integrity layers, once written, are outside the operator's control and cannot be withdrawn, whereas every availability layer in this architecture can be withdrawn by somebody. Section 5.8 gives the detail. An architecture of this kind provides strong, durable, adversary-resistant integrity and provides best-effort availability. Revision -00 did not draw the line and its Section 8.3 accordingly overstated the position. 5.2. Layer 1: Hash Integrity The hashing agent generates SHA-256, SHA3-512, and BLAKE3 fingerprints simultaneously before any network activity occurs. All subsequent layers anchor values bound to these fingerprints. Computing the fingerprints before any network operation is a security property and not merely an implementation ordering. It means the values submitted to external services are determined by the artifact alone and cannot be influenced by a response from any of those services. 5.3. Layer 2: Bitcoin Timestamping The Bitcoin agent submits the SHA-256 fingerprint to three independent OpenTimestamps [OTS] calendar servers. Each calendar aggregates submissions into a Merkle tree and commits the root to the Bitcoin blockchain. 5.3.1. Pending and Attested States An OpenTimestamps proof exists in one of two states, and this specification requires that they never be conflated. Pending. The proof carries a pending attestation: a calendar server URI and an undertaking to include the digest in a future Bitcoin commitment. A pending proof is a promise by a named third party. It carries no proof-of-work, establishes no block, and would resolve to nothing if the calendar discarded its aggregation state before its next commitment. Pending proofs are available within seconds of submission. Attested. The proof has been upgraded, after the calendar's commitment transaction confirms, to include a Bitcoin attestation: a Merkle path from the digest to a block header's merkle root, and the block height. An attested proof is verifiable against the Bitcoin blockchain by any party with a copy of the block headers, with no trust in the calendar operator, the REM implementation, or the author. Attestation typically becomes available within a few hours of submission. Implementations and documents publishing an OTS receipt MUST state which state it is in. Where the state is attested, the Bitcoin block height MUST be given. Where it is pending, the receipt MUST NOT be described as a Bitcoin timestamp, a blockchain anchor, or any equivalent formulation. The distinction is not pedantic. The security of the Bitcoin layer derives entirely from proof-of-work, and a pending proof has none. The difference between the two states is the difference between an assertion backed by the most expensive computation ever performed and an assertion backed by somebody's server staying up. 5.3.2. Calendar Independence Submission to three calendars operated by different parties means a single calendar's failure does not lose the timestamp. The three calendars used by the reference implementation are operated by two distinct organizations, which SHOULD be stated rather than presented as three independent operators. 5.3.3. Timestamp Semantics The submission moment is recorded by the implementation. The attested moment is the block time, which is later and is the only moment a third party can verify. The correct reading of an attested OTS proof is that the digest existed no later than the attested block. It is not a proof that the digest did not exist earlier, and it is not a proof of authorship. 5.4. Layer 3: REMID Identifier The REMID agent issues a resolvable identifier in the namespace defined in [DRAFT-REM-02]: REMID:YYYY.MMDD/[first 8 hex characters of the SHA-256 fingerprint] The REMID is bound to all three fingerprints in the record. An eight-character prefix is 32 bits. This is adequate as a human-facing handle and is not a cryptographic binding: 32 bits is well within reach of a birthday search, and an implementation MUST NOT treat REMID equality as evidence of artifact equality. Resolution MUST compare full fingerprints. Implementations SHOULD detect prefix collisions at issuance and extend the prefix for the colliding record rather than issue a duplicate identifier. 5.5. Layer 4: IPFS The IPFS agent pins the artifact to a pinning service, generating a content-addressed CID [IPFS]. The artifact is retrievable by any IPFS node using the CID alone. Two clarifications on -00. First, -00's Section 4.4 described pinning to "two independent Pinata IPFS providers", which its Section 8.3 then counted toward a claim that no single entity controls more than one layer. Two endpoints operated by one pinning service are one operator. Implementations SHOULD pin to services operated by genuinely distinct parties, and SHOULD state the operators. Second, IPFS is not durable storage. A CID is a permanent name for content; it is not a guarantee that anyone holds the content. If every pin lapses and no node retains the block, the CID remains valid and resolves to nothing. Implementations relying on IPFS for availability MUST maintain pins actively and SHOULD monitor retrievability rather than assume it. 5.6. Layer 5: Web Archiving The archiving agent submits record URLs to the Internet Archive Wayback Machine [IA] Save API, providing an independently operated dated capture. Revision -00 attributed to the Internet Archive a "documented 30-year preservation mandate". The author is unable to identify any such published commitment and the statement is withdrawn. The Internet Archive is a long-established nonprofit with a preservation mission; that is the accurate characterization. Captures may be removed in response to takedown requests or site owner exclusion, and archival coverage is best effort. 5.7. Layer 6: DOI Registration The deposit agent publishes the artifact to Zenodo [ZENODO], which registers a DOI via DataCite [DATACITE], providing citation infrastructure recognized by scholarly and institutional frameworks. A DOI is a persistent identifier, which is a commitment to resolution rather than to content. Zenodo permits record withdrawal, in which case the DOI resolves to a tombstone. The record of the deposit having occurred survives; the file may not. 5.8. What Each Layer Does and Does Not Guarantee +-------------+-----------+--------------------------------------+ | Layer | Property | Can be withdrawn by | +-------------+-----------+--------------------------------------+ | Fingerprint | Integrity | Nobody. Determined by the artifact. | | Bitcoin | Integrity | Nobody, once attested. A pending | | | | proof can be lost by a calendar. | | REMID | Discovery | The operator. Resolution depends on | | | | operator infrastructure. | | IPFS | Available | Pinning services, by letting pins | | | | lapse. No party can alter content. | | Web archive | Available | The archive, on takedown or | | | | exclusion. | | DOI deposit | Discovery | The repository, by withdrawal. The | | | and | DOI persists as a tombstone. | | | available | | +-------------+-----------+--------------------------------------+ The honest summary, which replaces the closing paragraph of -00's Section 8.3: Once a record is attested on Bitcoin, no party including the author can alter what the record says the artifact was, or when it existed. That property is durable and adversary-resistant. Whether the artifact itself remains retrievable depends on parties who can each withdraw independently. Every availability layer here is revocable by somebody. The architecture reduces the probability of total loss by using several unrelated providers; it does not eliminate it, and an adversary does not need to control Bitcoin mining consensus to make an artifact hard to obtain. They need only outlast a pinning subscription. This is a less dramatic claim than -00 made and it is the one that survives contact with an informed reader. 6. The Attested Genesis Record This section re-attests, with the corrections of Section 1.1, the record produced on 22 March 2026. The fingerprints are unchanged from -00; they were correct. 6.1. Artifact Metadata Title: First Triple-Fingerprint Permanence Record -- REM Protocol Author: Lawrence John Reilly Jr. Filename: First_Triple_Hash_Permanence_Record_2026.docx Byte Length: 11,489 octets Record ID: 08f11667-2128-4032-b8a1-3eb0e3752792 Issued: 2026-03-22T17:53:04.880923Z REM Version at issuance: 1.1 Protocol at issuance: draft-reilly-rem-protocol-01 Current protocol revision: draft-reilly-rem-protocol-02 Chain sequence number: 0 (genesis, per Section 4.5) BLAKE3 output length: 256 bits 6.2. Cryptographic Fingerprints Generated simultaneously at 2026-03-22T17:53:04Z. SHA-256 (32 octets): 29c75b03969a9a8138214f06dcd3d6edd7cfddb3a358031ef6142397 64127746 SHA3-512 (64 octets): 5794acd3b0330c343839330ad6a4ca2dec1e9bac3709c3f1d501d706 c18f2cc7e7e3946dfe6c440faac5e7e6c3edee21c5d0a6e75ef8e322 e399e30729589d06 BLAKE3, 256-bit output (32 octets): 6f7bf278ef5e72ae9746eb8b4e051358eec79442fdd40ab44c44914f 30d65015 6.3. Permanence Layer Attestations REMID: REMID:2026.0322/29c75b03 Zenodo DOI: 10.5281/zenodo.19164261 Zenodo Concept DOI: 10.5281/zenodo.19164260 Zenodo Record: https://zenodo.org/records/19164261 IPFS CID (artifact): bafkreibjy5nqhfu2tkatqikpa3onhvxn27h53m5dlabr55queolwietxiy IPFS CID (JSON record): bafkreif2sa43imr25dnwemrab4qllhe3sbi6y5jpdjje5jeywc5osagunq OpenTimestamps submission: 2026-03-22T17:53:05.961535Z, to three calendars operated by two organizations: alice.btc.calendar.opentimestamps.org bob.btc.calendar.opentimestamps.org finney.calendar.eternitywall.com 6.4. Bitcoin Attestation Status This section replaces the "Bitcoin OTS Calendar Receipts" material of -00 Section 5.3 and is the principal correction of this revision. 6.4.1. What -00 Published The three base64 values published in -00 decode to OpenTimestamps proofs in the pending state. Each contains the pending attestation marker followed by its calendar URI, and none contains a Bitcoin attestation. Their structure is: alice: 172 octets, pending, alice.btc.calendar. opentimestamps.org bob: 135 octets, pending, bob.btc.calendar. opentimestamps.org finney: 156 octets, pending, finney.calendar. eternitywall.com At the moment -00 was published, the Bitcoin layer of the attested record consisted of three calendar undertakings and no proof-of-work. Publishing them under a heading describing Bitcoin anchoring was incorrect. The submissions themselves were properly made and the record's watcher agent was designed to upgrade them on confirmation. The author expects that upgrade to have completed within hours of the original submission. The defect is in what -00 asserted, not in what the implementation did. 6.4.2. Attested Values The upgraded proof and its Bitcoin block height are to be inserted here before submission, obtained by running: ots upgrade First_Triple_Hash_Permanence_Record_2026.docx.ots ots info First_Triple_Hash_Permanence_Record_2026.docx.ots and reading the block height from the Bitcoin attestation line. The following fields MUST be populated: Bitcoin block height: [TO BE INSERTED] Block hash: [TO BE INSERTED] Block time (UTC): [TO BE INSERTED] Upgraded proof, base64: [TO BE INSERTED] This document MUST NOT be submitted with these fields unpopulated. If for any reason the upgrade cannot be obtained, the correct action is to state that the proof remains pending and to say why, not to republish the pending receipts without qualification. The pending receipts published in -00 are not reproduced here. They are preserved in the -00 archive for anyone wishing to verify this account, which is the appropriate place for a superseded artifact. 6.5. Cross-Layer Consistency Check One verifiable cross-check is available that -00 did not identify. The artifact's IPFS CID is a CIDv1 with the raw codec and a sha2-256 multihash. Its embedded digest is therefore extractable without retrieving the artifact. Decoding bafkreibjy5nqhfu2tkatqikpa3onhvxn27h53m5dlabr55queolwietxiy from multibase base32 yields version 1, codec 0x55, multihash code 0x12, length 32, and digest: 29c75b03969a9a8138214f06dcd3d6edd7cfddb3a358031ef6142397 64127746 which is identical to the SHA-256 fingerprint in Section 6.2. This is a genuine independent confirmation that the artifact pinned to IPFS is the artifact fingerprinted by the hashing agent and submitted to the calendars. It requires no trust in the implementation and no network access, and any reader can perform it with a base32 decoder. Implementations SHOULD publish this check, and verifiers SHOULD perform it before retrieving anything. The check is available only for the SHA-256 fingerprint, since the CID commits to that digest alone. It does not confirm the SHA3-512 or BLAKE3 fingerprints, which require the artifact itself. 6.6. Endpoint Migration Since -00 Every HTTP endpoint cited in -00 was under the hostname rem-protocol-agent-production.up.railway.app. The reference implementation has since migrated to remweb4.org, and the endpoints as cited in -00 should not be assumed to resolve. The current forms are: Resolver: https://remweb4.org/id/REMID%3A2026.0322%2F29c75b03 Verify: https://remweb4.org/verify/ REMID%3A2026.0322%2F29c75b03 JSON: https://remweb4.org/record/ 08f11667-2128-4032-b8a1-3eb0e3752792/json This is worth more than a footnote, because it is a demonstration of Section 5.1 using this document's own subject matter. Within five months, every HTTP endpoint in a permanence record moved. Nothing was lost, because nothing that mattered depended on them. The fingerprints are unchanged. The CID is unchanged and still resolves through any gateway. The DOI is unchanged. The Bitcoin commitment is unchanged and is independent of every hostname involved. The only things that broke were the URLs, which were the discovery layer. The lesson generalizes. A permanence architecture should be designed so that its weakest and most mutable component is the one whose failure costs least, and the location where a record is served is always more mutable than the record. Implementations MUST NOT make verification depend on operator-controlled endpoints, and documents attesting records SHOULD cite content-addressed and blockchain identifiers in preference to URLs wherever both are available. 7. Verification 7.1. Independent Fingerprint Verification Any party may verify the fingerprints in Section 6.2 by: (1) Retrieving the artifact from IPFS using the CID in Section 6.3, or from Zenodo using the DOI. (2) Computing SHA-256, SHA3-512, and BLAKE3 over the retrieved octets, taking BLAKE3 at 256-bit output. (3) Comparing all three against Section 6.2. A match confirms the artifact is byte-identical to the one fingerprinted at 2026-03-22T17:53:04Z. 7.2. CID Verification Without Retrieval Before retrieving anything, a verifier SHOULD decode the CID per Section 6.5 and confirm the embedded digest matches the published SHA-256 fingerprint. This costs nothing, requires no network access, and detects a substituted CID immediately. 7.3. Bitcoin Verification To verify the Bitcoin layer independently: (1) Obtain the .ots proof for the artifact. (2) Run the OpenTimestamps verifier against the artifact and the proof. (3) Confirm the verifier reports a Bitcoin attestation and a block height, not a pending attestation. A report of the latter means the proof has not been upgraded and the Bitcoin layer has not yet been established for that copy of the proof. (4) Confirm the reported block against an independently obtained copy of the Bitcoin block headers, rather than against a block explorer operated by a single party. Step (3) is the step -00 would have failed. 7.4. Chain Verification Where the record is presented as part of a Triple-Fingerprint Permanence Chain, the verifier MUST additionally perform the procedure of Section 4.6 and MUST report which of the three link algorithms it checked. 7.5. Live Verification Endpoint The implementation provides a verification page for this record at the URL in Section 6.6. That endpoint is a convenience. Every check in Sections 7.1 through 7.4 can be performed without it and SHOULD be, by any party whose interest in the record is adverse to the operator's. 8. Prior Art and Claims of Precedence Revision -00 asserted four claims of historical priority. This section replaces them. It first sets out the prior art the author is aware of, then states what is claimed, in a form a reader can test and rebut. 8.1. Related Work Evidence Record Syntax [RFC4998] and its XML counterpart [RFC6283]. This is the closest standardized prior art and -00 did not cite it, which was the most significant omission in that revision. ERS addresses precisely the problem that motivates multiple fingerprints: preserving the integrity of archived data across the lifetime of hash algorithms. Its mechanism is renewal. Before a hash algorithm weakens, the archive re-timestamps the existing evidence record under a stronger algorithm, producing a chain of timestamps each of which vouches for its predecessor. ERS also supports multiple hash algorithms within a single archive timestamp. The difference is one of posture rather than capability. ERS is sequential and custodial: it requires a party to act, correctly and in time, before each algorithm degrades, and it depends on a trusted timestamp authority [RFC3161] at each renewal. A record whose custodian stops performing renewals loses its protection. The construction in Section 4 is simultaneous and requires no future action: all three fingerprints exist from the first moment and continue to bind whether or not anyone is still paying attention. Against custodial failure, which is the dominant real failure mode in long-term archiving, simultaneity is the stronger posture. Against a well-run archive with reliable custody, ERS with renewal is at least as good and is a standard. Multihash and CIDv1 as used by IPFS [IPFS]. The multihash format is self-describing and explicitly supports multiple algorithms, and a CIDv1 names its hash function. Multi-algorithm content addressing is therefore established practice. What multihash provides is one digest under a named algorithm per identifier, not simultaneous fingerprints under several algorithms bound into one record, and it does not chain. OpenTimestamps [OTS]. Provides Bitcoin-anchored timestamping with calendar aggregation, and is used as a component here rather than being an alternative to this architecture. OTS is agnostic to what is timestamped and does not itself provide multi-algorithm fingerprinting, storage, identifiers, or chaining. Certificate Transparency [RFC6962] [RFC9162]. Establishes the pattern of an append-only Merkle log with inclusion and consistency proofs, which is the intellectual ancestor of most tamper-evident logging deployed since, including the chain in Section 4. CT is single-algorithm. Software Heritage, and content-addressed source archives generally. Long-running, large-scale content-addressed preservation with persistent identifiers. Single-algorithm. Blockchain notarization services, of which many exist. These generally provide timestamping plus storage without an open specification, without multi-algorithm fingerprinting, and without an identifier namespace. Linked timestamping literature, from Haber and Stornetta onward, which established hash-linking as the mechanism for relative ordering and is the basis of Section 4. 8.2. What Is Claimed Having reviewed the above, the author makes the following claims. Each is scoped, each identifies what would refute it, and none uses the phrase "first in history". Claim 1. The author is not aware of a prior open protocol specification that requires simultaneous SHA-256, SHA3-512, and BLAKE3 fingerprinting of a single artifact as a normative architectural element, with a publicly accessible running implementation. This would be refuted by a specification predating 22 March 2026 requiring those three functions together. Claim 2. The author is not aware of a prior hash-linked chain construction in which links are computed under three structurally distinct hash families and each link commits to all three predecessor links, as specified in Section 4.3. This would be refuted by any published entangled multi-algorithm chain construction. The author regards this as the more substantial of the two claims, and notes that it is a claim about this specification, dated to this document, not about the March 2026 record, which was a single record and not a chain. Claim 3. The record attested in Section 6 is, to the author's knowledge, the first record produced by a live implementation carrying all three fingerprints under an IETF-documented specification. This is a claim about a specific artifact and is the narrowest of the three. The following claims from -00 are withdrawn as unsupported: that the record is the first document in history so anchored; that the architecture is the first open permanence system to include BLAKE3 in production; that it is the first IETF-documented permanence protocol to address post-quantum resilience; and that it constitutes "a new category of permanence infrastructure rather than an extension of prior work". The last is the least defensible: this architecture is plainly an extension of prior work, specifically of linked timestamping, transparency logs, and evidence record renewal, and describing it otherwise does it no favors with readers who know that work. The author's search consisted of review of the IETF Datatracker and RFC series, the cryptographic literature on hash combiners and linked timestamping, and the documentation of the systems named in Section 8.1. It was not exhaustive and did not include a patent search. Readers aware of contrary prior art are invited to contact the author, and any identified will be recorded in a subsequent revision. 8.3. Defensive Publication Under [DRAFT-REM-02] Section 12.1, an artifact anchored by the dual-layer method constitutes a Prior Art Record: a public, dated, independently verifiable disclosure. The record attested in Section 6 and this specification are both published defensively and may be relied upon as prior art under 35 U.S.C. 102(a)(1) [USC-35-102] and equivalent provisions elsewhere. Two constraints apply. Anchoring a digest is not disclosure of content; a prior art record requires the content itself to be publicly accessible, which for this record it is, via IPFS and Zenodo. And the effective date is the anchoring date, which for the Bitcoin layer is the attested block of Section 6.4.2, not the submission moment. Nothing in this section is legal advice. 9. Security Considerations 9.1. Algorithm Independence The three algorithms use structurally independent constructions: Merkle-Damgard for SHA-256 [RFC6234], a Keccak sponge for SHA3-512 [FIPS202], and a binary tree mode for BLAKE3 [BLAKE3SPEC]. A cryptanalytic attack against one construction is unlikely to transfer to the others. This is the basis of the hedging claim in Section 3.4.3. It is not a basis for an additive security claim, and Section 3.4.3 should be read before any statement about combined strength is made. 9.2. Post-Quantum Posture Section 3.4.4 states the corrected position. In summary: the binding property is collision resistance; Grover does not meaningfully reduce it; the combination's collision resistance is approximately 256 bits from SHA3-512; and no post-quantum signature or key-establishment scheme is required for the record to remain sound, because the record's integrity rests on hashing rather than on public-key operations. Implementations that add signatures over records, which this specification does not require, do introduce public-key dependencies and SHOULD plan for post-quantum migration of those signatures separately. 9.3. Integrity Is Not Availability Section 5.8 sets out which layers can be withdrawn and by whom. The security consequence is that this architecture defends strongly against alteration and weakly against suppression. An adversary who cannot change what a record says may still be able to make the artifact inconvenient to obtain, by outlasting a pinning subscription or by pursuing takedowns. Implementations for which suppression is part of the threat model MUST provide for redundant custody under parties with divergent incentives, and SHOULD NOT assume that the number of availability layers is a proxy for resistance to a determined suppressor. 9.4. Pending Attestation Risk Between submission and upgrade, an OTS proof carries no proof-of-work. A system that treats submission as completion has a window, typically hours, during which its Bitcoin layer is a calendar operator's promise. Implementations MUST track upgrade status per record, MUST expose it in any interface presenting the record as anchored, and SHOULD alert when a proof remains pending beyond a configured threshold. Publishing a record as Bitcoin-anchored while its proof is pending is the specific defect corrected in Section 6.4, and it is an easy one to repeat. 9.5. Chain-Specific Considerations Fixed-length commitment. The record commitment M of Section 4.2 is fixed-length, and the only variable-length input is the metadata, which is committed under SHA3-512 before entering M. Implementers MUST NOT introduce variable-length fields into M, since doing so would expose the SHA-256 link to length-extension and ambiguity attacks that the fixed format currently forecloses. Canonicalization. Chain verification depends on both parties serializing metadata identically. Serialization disagreement produces a verification failure indistinguishable from tampering. Implementations MUST apply the canonicalization of Section 4.2 exactly and SHOULD publish the canonical metadata octets alongside the record so that a verifier need not reconstruct them. Braid as concatenation. Section 4.4 requires the braid to be a concatenation rather than a hash, so that no single algorithm becomes a point of failure for the entanglement. An implementation that compresses the braid for storage MUST retain the ability to reproduce the full 128 octets, since verification requires them. Completeness. As Section 4.7 states, a chain provides tamper-evidence and ordering, not completeness. An operator who never issues a record for an event produces no inconsistency. Deployments requiring completeness must attest an expected population separately. 9.6. Operator Trust and Centralization The reference implementation is operated by the author. A record's integrity does not depend on that operator once attested, which is the point of the design, but several things do depend on it: the REMID namespace, the resolver, the decision to issue a record at all, and the correctness of the fingerprinting agent at the moment of issuance. A verifier with an adverse interest to the operator SHOULD rely only on the checks in Section 7 that require no operator cooperation: fingerprint recomputation from an independently retrieved artifact, CID decoding, and Bitcoin verification against independently obtained block headers. Those three suffice to establish everything this architecture actually proves. 9.7. Prefix Collisions in REMID As noted in Section 5.4, the REMID's eight hex characters are 32 bits and are not a cryptographic binding. Implementations MUST NOT treat REMID equality as artifact equality, MUST compare full fingerprints on resolution, and SHOULD extend the prefix on detected collision. 10. IANA Considerations This document has no IANA actions. The REMID namespace is defined and administered by the REM Protocol specification [DRAFT-REM-02]. Registration of a URN namespace or well-known URI for REMID resolution is deferred to a future revision of that document. Should the chain construction of Section 4 progress, a future revision of this document may request registration of a media type for chain records. No such request is made here, since the construction has not yet been implemented in the form specified (Section 1.2). 11. References 11.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, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [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, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 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, . [BLAKE3SPEC] O'Connor, J., Aumasson, J-P., Neves, S., and Z. Wilcox-O'Hearn, "BLAKE3: one function, fast everywhere", January 2020, . [DRAFT-REM-02] Reilly, L., "Reilly EternaMark (REM) Protocol: Dual-Layer Digital Permanence Using DOI Archiving and Blockchain Timestamping", Work in Progress, Internet-Draft, draft-reilly-rem-protocol-02, 2026, . 11.2. Informative References [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, . [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, August 2007, . [RFC6283] Blazic, A.J., Saljic, S., and T. Gondrom, "Extensible Markup Language Evidence Record Syntax (XMLERS)", RFC 6283, DOI 10.17487/RFC6283, July 2011, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [JOUX] Joux, A., "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions", Advances in Cryptology - CRYPTO 2004, LNCS 3152, pp. 306-316, 2004, DOI 10.1007/978-3-540-28628-8_19. [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. [BITCOIN] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash System", October 2008, . [OTS] Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, Distributed Timestamping with Bitcoin", 2016, . [IPFS] Benet, J., "IPFS: Content Addressed, Versioned, P2P File System", arXiv:1407.3561, 2014, . [IA] Internet Archive, "Wayback Machine Save Page Now", . [ZENODO] European Organization for Nuclear Research and OpenAIRE, "Zenodo", 2013, . [DATACITE] DataCite, "DataCite Metadata Schema Documentation", Version 4.5, 2024, . [NISTPQC] National Institute of Standards and Technology, "Post-Quantum Cryptography Standardization", . [EIDAS] European Parliament and Council, "Regulation (EU) No 910/2014 on electronic identification and trust services for electronic transactions in the internal market (eIDAS)", July 2014. [ESIGN] United States Congress, "Electronic Signatures in Global and National Commerce Act", 15 U.S.C. 7001 et seq., June 2000. [UETA] National Conference of Commissioners on Uniform State Laws, "Uniform Electronic Transactions Act", 1999. [USC-35-102] United States Code, "Conditions for patentability; novelty", 35 U.S.C. 102. Appendix A. Changes from -00 A.1. Substantive Corrections A.1.1. Bitcoin attestation state. The receipts published in -00 Section 5.3 were pending calendar attestations, not Bitcoin attestations, and were presented as the latter. Section 5.3.1 defines the two states normatively and Section 6.4 sets out what was published and what must replace it. A.1.2. Post-quantum analysis. The security table of -00 Section 3.4 conflated collision and preimage resistance and applied Grover to the property that does not bind a permanence record. Section 3.4 is rewritten, the table replaced, and the claim of exceeding a "NIST post-quantum threshold" withdrawn as a category error. A.1.3. Combined security. The implication in -00 that three algorithms multiply security is replaced by the hedging claim of Section 3.4.3, following [JOUX], with an explicit prohibition on additive claims derived from this specification. A.1.4. Layer independence contradiction. Section 4.4 of -00 described pinning to two Pinata endpoints while Section 8.3 asserted that no single entity controlled more than one layer. Corrected in Section 5.5. The three OTS calendars are likewise now described as operated by two organizations rather than three. A.1.5. Internet Archive mandate. The assertion of a "documented 30-year preservation mandate" is withdrawn as unsupported (Section 5.6). A.1.6. Integrity versus availability. The closing claim of -00 Section 8.3, that erasure would require simultaneous control of Bitcoin consensus, IPFS, Zenodo, and the Internet Archive, is replaced by the layer analysis of Sections 5.1 and 5.8, which distinguishes what cannot be altered from what can be withdrawn. A.1.7. Precedence claims. The four claims of -00 Section 7 are withdrawn and replaced by three scoped, refutable claims in Section 8.2, with prior art in Section 8.1 including [RFC4998], the most significant omission from -00. A.2. New Material A.2.1. The Triple-Fingerprint Permanence Chain (Section 4). An entangled three-algorithm hash chain: fixed-length record commitment, three link values over a common input, and a concatenated 128-octet braid that privileges no algorithm. Includes verification procedure, security analysis, and algorithm retirement without chain rewrite. A.2.2. Cross-layer consistency check (Section 6.5). The artifact's CIDv1 embeds a sha2-256 multihash whose digest is identical to the published SHA-256 fingerprint. This is an independent confirmation available without network access, which -00 did not identify. A.2.3. Endpoint migration (Section 6.6). Every URL cited in -00 has moved. The section records the current forms and draws the general lesson about placing dependence on operator-controlled endpoints. A.2.4. BLAKE3 caveats (Section 3.3). Extendable output requires a fixed declared length; BLAKE3 is not standardized by NIST, the IETF, or ISO, and should not be a sole fingerprint in regulated deployments. A.2.5. REMID prefix collision (Sections 5.4, 9.7). Eight hex characters are 32 bits and not a cryptographic binding. A.2.6. Implementation status (Section 1.2) per [RFC7942], stating plainly that the chain construction is specified in advance of a conformant implementation. A.2.7. Defensive publication (Section 8.3) under [DRAFT-REM-02] and 35 U.S.C. 102(a)(1). A.3. Editorial and Reference Corrections Title changed to reflect that the document now specifies a chain rather than attesting only a record. Stream designation corrected from "Independent Submission", which denotes the ISE stream, to "Network Working Group". License text reference corrected from Simplified BSD to Revised BSD per the current Trust Legal Provisions. Status of This Memo boilerplate updated from the obsolete 1id-abstracts.html and shadow.html references to the current Datatracker URL. Agent numbering, which in -00 ran 1, 2, 3, 4, 5, 5.5, 7 while asserting seven agents, is no longer used; layers are described by function. Reference to the REM Protocol updated from -01 to -02. Added [RFC3161], [RFC4998], [RFC6283], [RFC6962], [RFC7493], [RFC7942], [RFC9162], [RFC3339], [RFC8259], [JOUX], and [USC-35-102]. The claim that SHA-256 is "recognized under" ESIGN, UETA, and eIDAS is softened in Section 3.1, since those instruments concern trust services generally and do not mandate digest algorithms. Appendix B. Genesis Chain Test Vectors These vectors are computed from the published fingerprints of the genesis record (Section 6.2) under the construction of Section 4. They are reproducible by any implementer. Canonical metadata (I-JSON, keys sorted, no whitespace, no trailing newline), shown wrapped for readability but hashed as a single line with no inserted characters: {"issued":"2026-03-22T17:53:04.880923Z","record_id":"08f1166 7-2128-4032-b8a1-3eb0e3752792","rem_version":"1.2","remid":" REMID:2026.0322/29c75b03"} H_meta = SHA3-512(0x00 || meta), 64 octets: 34770336415cf214359cc75ffa17f40ceb895988497162a1280afa8f1510 af22fed183f8daf1ac77ba0204834f5d0e3bc99cefcd73818d7ecc596a1a 7739f9da M = 0x01 || uint64be(0) || fp256 || fp3 || fpb3 || H_meta Length: 201 octets. braid_prev for seq 0: 128 octets of 0x00. Link input: 0x02 || braid_prev || M, being 330 octets. L_sha256, 32 octets: e66fe9fa7edc6b77301f559be4f4b460ccdfcbc836459df222528203c5fa 572d L_sha3, 64 octets: a7375ed8cf0c861abd6b3f3a79067299ce0c8999945cc0f3dac53b4f5a43 40decc3105cc37405fcd699bcb11b1dc49a7a781d94ca1a38cd8c5fce15a 48bb2790 L_blake3, 32 octets at 256-bit output: 5900f417b10ee04427a234ab34c64342c3c9b603630dc3e4288284ec1094 a2c5 braid_0 = L_sha256 || L_sha3 || L_blake3, 128 octets. Implementers SHOULD confirm all three link values before proceeding, since a mismatch at seq 0 indicates a canonicalization or domain-separation error that would otherwise propagate silently through every subsequent record. Note that the metadata above carries "rem_version":"1.2" while the genesis record was issued under REM version 1.1 (Section 6.1). The metadata here is the chain record's metadata, constructed under this specification, not a reproduction of the original record's metadata envelope. An implementation reproducing these vectors MUST use the octets exactly as given. Author's Address Lawrence John Reilly Jr. REM Technologies & Consulting, LLC Email: lawrencejohnreilly@gmail.com GitHub: https://github.com/lawrencejohnreilly-creator/rem-protocol IETF Datatracker: https://datatracker.ietf.org/person/lawrencejohnreilly@gmail.com Live System: https://remweb4.org/