Docs / How PubPhys proves what and when
How PubPhys proves what and when
A researcher needs to be able to say: I wrote this problem (or this solution), and it existed no later than this date. An ordinary website cannot give that: you have to take its word for it, and a site can close, change hands, be hacked or be pressured. PubPhys is built so that the proof does not depend on PubPhys. It can be checked by a program that does not need this site, and every part that matters is confirmed by parties PubPhys does not control.
Four parts, in plain words
1. The fingerprint of a text. From any text one can compute a short fingerprint (a SHA-256 hash). Change a single letter and the fingerprint becomes completely different, and nobody can find another text with the same fingerprint. So the fingerprint always tells whether a text is the same.
2. The PubPhys seal. When a record arrives, PubPhys puts a digital seal on it (an Ed25519 signature). The seal means one thing only: PubPhys received this. The pattern of the seal (the public key) is published in several places, on the keys page, in the domain's DNS and in a public repository, so it can be compared without trusting a single source.
3. A log book whose pages cannot be removed. Every record is pasted into one public log. The log is a tree of fingerprints that adds up to one fingerprint of the whole book, so changing, removing or inserting any earlier record changes that overall fingerprint. Whenever new records have arrived (checked every hour), PubPhys draws a line: the log has N records, and this is its fingerprint. The line goes to places PubPhys does not control:
- Rekor, the public log of the Sigstore project, run by others, whose own state is countersigned by independent witnesses;
- Bitcoin, through the OpenTimestamps service;
- a public git repository,
Galitski-group/pubphys-log, which anyone can copy.
Each new line must continue the previous one, which is checked with a short mathematical proof. If PubPhys tried to remove or rewrite anything, the new line would no longer agree with the one already in Rekor and in every copy of the repository. When nothing new arrives, the log does not change and no new line is drawn.
The public repository holds only what checking needs: the signed log lines, their Rekor entries and Bitcoin proofs, the records that introduce or revoke PubPhys's keys, copies of ORCID's public keys, the public keys file and the checking program. It holds no personal data and no documents: the records of people (appointments and their ORCID tokens), problems, solutions and uploaded files stay on this site, and the log carries only their fingerprints.
4. A date from Bitcoin. The fingerprint of every record is sent to OpenTimestamps, which writes it into the Bitcoin blockchain. A few hours later there is a proof that this fingerprint existed no later than block number such-and-such. Nobody can fake that date, neither PubPhys nor anyone else: it would mean rewriting Bitcoin.
What you have to trust, and what you do not
| Part | Who vouches for it | Do you need to trust PubPhys? |
|---|---|---|
| The text is unchanged | Mathematics (SHA-256) | No |
| The date | Bitcoin, through OpenTimestamps | No |
| Nothing was removed or rewritten later | Rekor and the public mirror | No |
| Which ORCID account confirmed a record | ORCID (a sign-in token ORCID signed for exactly these records) | No, while ORCID's key is known to you (see below) |
| PubPhys received the record | The PubPhys seal, checked against keys you pinned | Only that its key was not stolen at that moment |
What happens to a record, step by step
- A record (a topic, a problem, later edits, claims and reviews) arrives.
- PubPhys computes its fingerprint and puts its seal on it.
- The record is pasted into the log under the next number.
- Its fingerprints are sent to Bitcoin.
- The next line of the log covers it together with everything before it and goes to Rekor, Bitcoin and the public repository.
- For every record you can download a proof: one file with everything needed to check it.
Which ORCID account confirmed a record
Records written by a person are confirmed through
ORCID. Before PubPhys stores them, the person signs in at ORCID with a
one-time value computed from the exact fingerprints of the records listed on the confirmation page, and ORCID returns
a token it has signed. Such records are appointments of editors and referees, new problems (their first revision),
results (claim), their withdrawals (withdrawal), contests (contest), and editors' and
referees' decisions (review: accept, reject, not accepted at screening, recommend, do not recommend, and on contests
substantive, not substantive, upheld, dismissed, credit, reversed); each appears in the log
with its type. PubPhys still writes some records on its own key: seed records, removals, acceptances carried over a
cosmetic revision, and the acceptance of a revision that changes a problem's substance (or of any topic revision) that
PubPhys publishes. The token, kept with the records, names the ORCID iD and, as ORCID issues it, the given and
family names held at ORCID. PubPhys cannot forge ORCID's signature: the token shows that whoever held that ORCID
account signed in at ORCID for exactly these fingerprints. (The list itself was shown by PubPhys's page, and the check
that the sign-in was fresh is made by PubPhys when it accepts the records, not by the verifier later.) You agree to
this when you sign in; the token is published with the records.
To check a token, a verifier needs ORCID's public key. ORCID publishes only the keys it uses now; a replaced key may no longer be published. So PubPhys records ORCID's keys as it sees them, logs each set in Rekor, and asks the Wayback Machine to capture them every 12 hours. A verifier trusts an older key only as the archive shows it, never because PubPhys says so. Logging in Rekor proves when PubPhys saw a key set, not that ORCID published it.
Deleting an account. The records stay in the log for ever (that is the point of the log), with the ORCID iD in them. An account that has signed nothing deletes itself on the account page; any other asks for deletion there, and once any appointment it holds has been revoked, an admin deletes the account (Accounts). PubPhys removes the profile and from then on serves the records without the ORCID token, so what PubPhys serves no longer confirms which account signed them (the tokens were never in the public repository). Copies already downloaded or cached cannot be recalled. A suspended account that is deleted stays suspended: its iD cannot be used for a new account until the admin lifts the suspension (Accounts).
Provisional proofs. A record confirmed a moment ago is in a log line that Rekor and the public repository may not hold yet. Its proof says so (witness: not checked) until that line, or a later one, is logged in Rekor and the repository; download it again later, or let the command-line tools find the line. When a person's records are stored, PubPhys also signs a promise: this record will be in a logged line within two hours. The verifier reports the promise as kept when the Rekor entry recording such a line is covered by a Rekor checkpoint that an independent witness countersigned before the deadline; otherwise it says it could not judge it. PubPhys's administrators watch for missed promises (there is no public page yet).
Check it yourself
The verify page checks a proof in your browser. It is convenient, but every result there trusts the code this site serves you. The command line below does not.
On a topic or problem page, press Download record (.json), then, with Node.js installed:
# the checking program: the signed release v0.2.0, built by GitHub Actions and attested with Sigstore
gh release download v0.2.0 -R Galitski-group/pubphys-verifier
gh attestation verify pubphys-verifier-v0.2.0.tar.gz --repo Galitski-group/pubphys-verifier \
--signer-workflow Galitski-group/pubphys-verifier/.github/workflows/release.yml
tar xzf pubphys-verifier-v0.2.0.tar.gz && V=$PWD/pubphys-verifier-v0.2.0/verifier
# the data: the public log
git clone https://github.com/Galitski-group/pubphys-log && cd pubphys-log
dig +short TXT _pubphys.pubphys.com # compare with the recovery fingerprint pinned in the release
node $V/fetch-trust.mjs --bitcoin > my-trust.json # not trust.json: that is the file it reads
node $V/fetch-witness.mjs --bundle ~/Downloads/pubphys-*.bundle.json --trust my-trust.json \
--sigstore-trusted-root trusted_root.json --site https://pubphys.com > trust-witness.json
node $V/fetch-orcid-keys.mjs --trust trust-witness.json --live > trust-full.json # records signed with ORCID
node $V/pubphys-verify.mjs ~/Downloads/pubphys-*.bundle.json --trust trust-full.json --bitcoin
trusted_root.json is Sigstore's own list of Rekor keys, which you obtain from Sigstore through its
signed TUF repository (for example with the cosign or sigstore tools), never from
PubPhys. If you skip that step, --fetch-sigstore-root-unverified downloads it from Sigstore's GitHub
repository instead, and the witness result is then only as good as that download.
The program reports each part separately:
pubphys-verify and its two helper scripts) reads. Right: what it reports, each part on its own; it also checks the file's structure, and identity follows in phase 2. The verifier does not have to trust the PubPhys site, so a proof can still be checked if the site is gone.- content: the text is unchanged (the fingerprints match);
- platform: PubPhys received it (the seal matches the published key);
- log and witness: the record is in the log, and the log agrees with the line logged in Rekor;
- time: the date is confirmed by Bitcoin;
- identity: the author is confirmed by ORCID (only records written by a person; the seed collection has no author in this sense);
- promise: shown beside the parts, kept or not judged. An unjudged promise never makes a record fail; a promise with a bad seal, or for another record, fails the log part.
The program does not trust this site: it starts from the recovery key you took from DNS, checks every key record itself, takes the log line from the mirror and accepts it only if Rekor logged it, and takes the date from Bitcoin block headers (from blockstream.info by default; your own Bitcoin node removes that last bit of trust).
If the site is hacked
An intruder could steal the seal and stamp anything with it. For that case there is a spare key (the recovery key). It is never on a server: two copies are kept offline by two people responsible for the project. With it, two notices are published: the old seal is revoked and the new seal is this one. Everything sealed before the revocation stays valid, because its date is already fixed in Bitcoin and cannot be faked afterwards. Anything sealed with the stolen key after the revocation is rejected by the verifier.
The thief could also have used the stolen seal to introduce a seal of their own before being caught. The verifier
therefore trusts a seal only if it descends from the spare key through seals that are not revoked: once the stolen
seal is revoked, every seal whose trust depends only on it loses trust too, whenever it was made, and cannot revoke
anything. PubPhys can then introduce again, with the spare key, any of those seals that were legitimate. The exact rule is published
with the verifier (verifier/TRUST.md in the public repository).
If the site disappears
A downloaded proof keeps working. Checking it needs only the file itself, the public Bitcoin blockchain, Rekor (or a copy of the public repository) and the published keys. Neither the site nor the domain is needed.
What this does not prove
- Who had the idea first. A proof says the text existed no later than a certain date. An idea published earlier elsewhere has priority.
- Real-world identity. ORCID confirms that the author controls a certain ORCID account; it does not check a passport.
- That a solution is correct. The seal means received, not right. Correctness is for referees and the community.
- The order of near-simultaneous records. Records whose Bitcoin dates are less than 36 blocks (about six hours) apart count as simultaneous.
- Anything said in a comment. Comments are site content, not records: they are not signed, stamped or logged, and carry no priority (comments).
One limit of the log today: if PubPhys showed two different versions of the log to two different people, this is caught when the two versions are compared (both lines are in Rekor for good), but nobody independent scans for it yet. Independent witnesses countersign Rekor's own log, which the promise check uses; they do not yet countersign PubPhys's log lines directly.
Dates on records
A record also carries a created time chosen by whoever made it. It is a claim and never a priority date; the Bitcoin date is the one that counts. "Waiting for Bitcoin" usually means a few hours. The seed collection was compiled on 1 and 2 October 2026 and signed at launch, so its records show the launch time; the list of every imported row with its fingerprint was timestamped separately before the records were signed (seed collection).
Glossary
- Fingerprint (hash)
- A short value computed from data; any change to the data changes it.
- Seal (signature)
- A value only the holder of a private key can produce, checkable by anyone with the public key.
- Log line (checkpoint)
- A signed statement of the log's size and overall fingerprint.
- Proof (bundle)
- One file with a record and everything needed to check it.
- Rekor
- A public, append-only log run by the Sigstore project: docs.sigstore.dev.
- OpenTimestamps
- A free service that writes fingerprints into Bitcoin: opentimestamps.org.
- Recovery key
- The offline spare key that introduces and revokes PubPhys keys.