]> Global Innovation Technology LTDA

Sao Paulo, SP Brazil orlando@globalcopyrights.org https://orcid.org/0009-0002-2533-7446

Global Innovation Technology LTDA

Sao Paulo, SP Brazil nelson@globalcopyrights.org

Global Innovation Technology LTDA

Sao Paulo, SP Brazil lucas@globalcopyrights.org

Global Innovation Technology LTDA

Sao Paulo, SP Brazil felipe@globalcopyrights.org

Global Innovation Technology LTDA

Sao Paulo, SP Brazil clara@globalcopyrights.org

General Independent Submission proof of existence anteriority timestamping permissioned ledger copyright This document specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger whose purpose is to produce verifiable evidence that a given digital work already existed no later than a given point in time, under an authorship claim made by an identified account. ProtectChain records only cryptographic digests and pseudonymous identifiers; the work itself never enters the ledger. Because all initial authorities may be operated by a single organization, every block is also anchored to independent public time references, so that the upper bound on a record's date does not rest on the operator's assertion. This document is deliberately explicit about the limits of the evidence produced: an anchor establishes that data existed no later than a given instant; it does not establish the exact instant of creation, nor does it establish authorship or originality.

Introduction Under the Berne Convention and most national legislation, copyright arises automatically upon creation of a work; registration is not a condition of protection. The practical difficulty is therefore not obtaining the right, but proving, in a later dispute, that a particular work existed at a particular time and was claimed by a particular party. Services that produce such evidence are common. Their recurring weakness is that the recorded date rests entirely on the provider's own database and clock: an operator could, in principle, insert a record and assert an earlier date for it. ProtectChain addresses that weakness by combining three mechanisms:

1. a hash-chained ledger in which each block is signed by the authority that sealed it;
2. independent co-signature by additional authorities, each of which recomputes the block rather than trusting the sender;
3. anchoring of each block into public time references that the operator does not control.

The work itself is never transmitted to or stored in the ledger. Only digests and pseudonymous identifiers are recorded, which keeps the confidentiality of the work independent of the number of participants in the network.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Definitions

Record:

The set of digests and metadata submitted for a work. It never contains the work itself.

Block:

A batch of sealed records, linked to its predecessor by hash and signed by a sealer.

Authority:

A node permitted to validate and co-sign blocks, identified by an Ed25519 public key. Roles are sealer (produces blocks) and validator (validates and co-signs).

Anchor:

External evidence that a block existed no later than a given instant, obtained from a public time reference.

Quorum:

The number of distinct authority signatures required for a block to be considered corroborated.

Data Model

Records A record carries the SHA-256 and SHA-512 digests of the work, an opaque reference to the submitting account, an optional declared creation date, an optional certificate code, and the instant at which the node received it. Implementations MUST NOT place the content of the work, or any direct personal data, in a record. The record identifier is computed as the SHA-256 of the following canonical form, with fields separated by a single LF character (0x0A): Absent optional fields are represented as the empty string. All digests are lowercase hexadecimal.

Blocks A block links to its predecessor and commits to the records it contains: The genesis block has index 1, a prev_hash of sixty-four ASCII zeros, and no records. Signatures use Ed25519 and are computed over the lowercase hexadecimal representation of block_hash.

Merkle Root with Domain Separation A naive Merkle construction that duplicates the final element when a level holds an odd number of nodes admits distinct record sets that produce identical roots. Implementations MUST therefore use domain separation between leaves and interior nodes, in the spirit of : The prefixes 0x00 and 0x01 are single octets, and h, a and b are the 32-octet binary digests, not their hexadecimal encodings. When a level holds an odd number of nodes, the final element MUST be promoted unchanged to the next level; it MUST NOT be duplicated or paired with itself. The root is published in lowercase hexadecimal.

Consensus Only authorities produce and validate blocks. Each node publishes the authority list, so that any verifier can determine which keys may legitimately co-sign. There is no mining and no proof of work; the identity of operators is known and auditable.

Co-signature Protocol

1. The sealer seals pending records into a block, computes block_hash, and signs it.
2. The sealer sends the block header and the list of record_hash values to the other authorities. It MUST NOT send the content of any work.
3. Each validator decides independently () and, if it approves, mirrors the block locally and returns its signature over block_hash.
4. The sealer MUST accept a co-signature only if the signer is a known active authority and the signature verifies against that authority's public key.
5. A block reaches quorum when it holds signatures from distinct authorities in a number at least equal to the quorum ().

Independent Validation Before co-signing, a validator MUST verify, on its own and without taking any value from the sender on trust, that:

1. the sealer is present in the active authority list;
2. block_hash, recomputed from the received fields, matches;
3. the Merkle root, recomputed from the received record_hash values, matches;
4. the sealer's Ed25519 signature over block_hash verifies;
5. prev_hash matches the block it already holds at index-1, if any;
6. it has not already co-signed a different block at the same index.

A validator that merely echoed what it received would add no evidence. It is the independent recomputation that gives a co-signature meaning: a block carrying N signatures indicates that N machines, in distinct locations, independently reached the same result.

Mirroring and Synchronization A validator replicates the chain; it MUST NOT maintain a competing one. Upon receiving a block whose predecessor it does not hold, it MUST obtain the missing blocks from an authority and revalidate each one before adopting it. Data arriving over the network is never adopted on trust, even when it originates from an authority. Consequently, only the sealer creates the genesis block. A validator that created its own genesis would diverge on prev_hash and reject the legitimate chain. A validator stores only record_hash values, which suffice to recompute the Merkle root and to serve inclusion proofs, without ever holding the work.

Quorum and Fault Tolerance Quorum is the simple majority of active authorities, counting the sealer's own signature. Quorum by number of authorities

Authorities	Quorum	Tolerated failures
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2

A block that has not yet reached quorum is not invalid; it is less corroborated. It remains chained, signed and publicly anchored. This distinction is deliberate: the evidence available to a submitter MUST NOT depend on the availability of third parties.

Separation of Recording and Consensus Recording a work and obtaining consensus are distinct, asynchronous operations.

• Recording MUST NOT block while waiting for co-signatures.
• Propagation MUST occur outside the submitter's request path, in a periodic process.
• That process MUST reprocess blocks that have not reached quorum, so that the network converges without operator intervention when an unavailable authority returns.

Availability Model Authorities are expected to sit behind network address translation in distinct sites, and connectivity between peers may be asymmetric or intermittent. This specification treats that as normal rather than exceptional:

• the sealer MUST continue to operate when it can reach no validator;
• an unreachable validator MUST NOT prevent sealing, anchoring, or recording;
• convergence MUST be eventual and automatic.

Anchoring to Public Time References Because all initial authorities may belong to a single operator, each block is additionally committed to public references that the operator does not control.

Time-Stamp Tokens Implementations SHOULD obtain a time-stamp token over block_hash from one or more independent Time-Stamping Authorities as defined in . This yields an immediate signed upper bound on the block's date.

Distributed Ledger Anchoring Implementations SHOULD additionally commit block_hash to a public distributed ledger whose history the operator cannot rewrite, using an aggregation scheme so that many commitments share a single ledger transaction. Such proofs are inherently asynchronous: they mature only when the underlying ledger confirms. Until then, the immediate guarantee is provided by .

Clock Discipline Nodes SHOULD discipline their clocks against authoritative time sources using NTP . Clock accuracy serves precision and record-keeping; the property that makes a date assertable against third parties comes from the anchors, not from the local clock. A well-disciplined clock narrows, but does not eliminate, the window described in .

Scope and Limits of the Temporal Evidence This section is deliberately explicit. A specification about evidence loses credibility if it overstates what it proves. Implementations and accompanying materials MUST NOT claim more than what is described here.

What the Evidence Demonstrates An anchor over block_hash demonstrates, verifiably by third parties and without relying on the operator's assertion, that the block -- and, by Merkle inclusion, every record within it -- already existed no later than the instant of the anchor. Because record_hash incorporates the digests of the submitted file, this is equivalent to demonstrating that a file with exactly that content already existed by that instant.

What the Evidence Does Not Demonstrate

1. It does not fix the instant of creation. The anchor is an upper bound: it shows the content was not created after that instant.
2. It does not validate the block's created_at field nor the submitter's declared creation date. Neither is corroborated by the anchor; only the anchoring instant is.
3. It does not establish authorship or originality. The submission is a self-declaration.
4. It does not prevent submission of a third party's work. A submitter obtains evidence that the file existed by a given instant, which confers no right over it.

The Trust Window and Its Mitigation Between the created_at value written into a block and the instant of anchoring there is a window within which the accuracy of the date depends on the operator's honesty. A dishonest operator cannot backdate a record beyond the anchor, since the anchor is always later; it could, within the window, declare a created_at slightly earlier than reality. Mitigations:

• Implementations MUST anchor each block immediately after sealing, keeping the window in the order of seconds.
• Material citing a proven date SHOULD present the anchoring instant as the demonstrated date, and created_at or any declared date as asserted information.
• Federation with independent operators reduces the window to a problem of collusion between distinct parties.

Recording early is what creates value: the evidence is as strong as its earliest anchor is old. No technology can retroactively demonstrate that data is older than its first anchor.

Data Minimization The following table summarizes what does and does not reach the ledger. Data placement

Data	Enters the ledger
The work itself	Never
SHA-256 / SHA-512 of the work	Yes
Work and certificate identifiers, dates	Yes
Submitter identity	Only as an opaque pseudonymous reference
Name, e-mail, documents, address	Never

Identifiers recorded in the ledger are pseudonymous, not anonymous: alone they reveal nothing, but they can be relinked to a person by whoever holds the operator's account database. Implementations MUST NOT place direct personal data in the ledger, nor any metadata that identifies a person on its own. Deployments subject to data protection regimes that grant a right to erasure face a known tension with append-only, anchored records. The approach taken here is minimization and unlinking rather than deletion: personal data resides exclusively outside the ledger and remains erasable; once the link between the pseudonymous reference and the person is destroyed, the ledger entry retains only an irreversible digest and opaque identifiers. Submitters MUST be informed, before recording, that digests and pseudonymous identifiers are written permanently.

Admission of Additional Authorities A candidate authority MUST satisfy the following. None of these is ceremonial; each exists so that the candidate's co-signature carries meaning.

1. Verifiable identification of the operator and formal acceptance of the network's terms.
2. Independence: the candidate MUST NOT be controlled by the same entity as another active authority. Two authorities under common control do not add independence.
3. A distinct site: separate physical machine, provider and network path. Placement in a different jurisdiction from existing authorities is RECOMMENDED.
4. Clocks disciplined per .
5. Locally generated Ed25519 key material. The private key MUST NOT leave the node, including in backups or images.
6. Participation over a private, authenticated and encrypted network. The consensus API MUST NOT be exposed on a public address.
7. Authentication of inter-node calls by signature (). Shared secrets MUST NOT be used between authorities.

Admission proceeds by request, review, network provisioning, a probation period during which the candidate replicates and revalidates the chain without co-signing, and finally addition of its public key to the authority list, at which point quorum is recomputed. Removal of an authority MUST be possible at any time and consists of withdrawing its public key from the authority list. Revocation MUST NOT invalidate blocks the authority previously co-signed: each signature remains verifiable against the key that produced it, and the date remains supported by the anchors. Revocation applies prospectively.

Inter-Node Authentication What authorizes a block is the Ed25519 signature of the authority that sealed it, verified against the authority list. No transport credential substitutes for that: a block carrying an invalid signature is rejected even when it arrives over a perfectly authenticated channel. Calls between authorities MUST be authenticated by the Ed25519 signature of the issuing node, verified against the authority list. Shared secrets MUST NOT be used between authorities, because they make an individual participant neither distinguishable nor revocable. Each request carries the issuing node identifier, a timestamp, a nonce and a signature over the canonical form: A receiver MUST reject requests outside a bounded clock tolerance, MUST require the issuer to be an active authority, MUST verify the signature against the registered public key, and MUST reject reuse of a nonce within the tolerance window. A tolerance of 300 seconds is RECOMMENDED.

Security Considerations Confidentiality of the work. The work never enters the ledger (). Adding authorities therefore widens corroboration without widening exposure of content. Backdating. Anchoring prevents assigning a record a date earlier than its anchor. The residual window between created_at and anchoring is addressed in . Implementations that omit anchoring reduce the guarantee to the operator's assertion. Merkle malleability. Domain separation () prevents distinct record sets from yielding the same root, and promotion of the odd element removes the ambiguity introduced by duplication. Compromise of a sealer key. An attacker holding a sealer's private key could forge new blocks, but could not alter blocks already anchored, since their digests are committed externally. Key rotation MUST be recorded in the chain, and quorum limits the damage: forged blocks would fail independent validation by other authorities. Equivocation. A validator MUST NOT co-sign two distinct blocks at the same index; implementations MUST keep persistent state sufficient to detect this across restarts. Replay. Inter-node authentication binds method, path, timestamp, nonce and body digest (). Without nonce rejection, a captured request could be replayed within the clock tolerance. Digest strength. Evidence rests on SHA-256 and SHA-512 jointly; a forgery would require simultaneous collisions in both with semantically useful content. Should either function be weakened, deployments will need a migration path that re-anchors existing records under a stronger function; this document does not specify one. Availability is not integrity. Loss of quorum reduces corroboration but never causes acceptance of an invalid block. Conversely, a reachable but dishonest authority cannot cause an invalid block to be accepted by honest validators, since each validates independently. Transport. Private, authenticated and encrypted transport between authorities is defence in depth, not the foundation of the evidence: a forged block would be rejected by signature and chaining checks regardless of the channel. Deployments concerned with long-term confidentiality of consensus traffic SHOULD select transports offering protection against future cryptanalytic advances, including those enabled by quantum computation. Legal weight. The evidence produced is one element of proof, subject to evaluation by the relevant forum. It is not an absolute legal presumption in any jurisdiction, and it does not replace official registration where such registration carries specific effects.

IANA Considerations This document has no IANA actions.

References Normative References Informative References World Intellectual Property Organization

Acknowledgements The design of the Merkle construction in follows the domain-separation approach established by Certificate Transparency .