Publishing with proof: signed reports, a Bitcoin ledger and a DOI

At 03:00 UTC this morning, a Bitcoin block with the height 974,615 was mined somewhere in the world. Folded into it, through a chain of hashes too small for anyone to notice, is a fingerprint of every file in a library in my apartment in Iași: 331,631 entries, in 15 daily epochs, every one of them confirmed.

Nobody who mined that block knows me. That is exactly why it is useful.

This is the story of how I went from publishing claims to publishing proof: first for threat-intelligence reports, then for a whole library, and finally for a book with a permanent identifier in a public research archive. Three steps, over six months, and one question underneath all of them: why should anyone believe one person with one machine?

Contents · 10 sections

In one minute #

• In April 2026 I started publishing reports about the attacks my lab receives. They were careful and sourced, and a reader had to take my word for every one of them.
• On 19 July I sealed them: every report’s data is now signed with a key, organised in a Merkle tree, and timestamped in Bitcoin. That evening, 630 reports were sealed and published.
• On 5 October I did the same for my library: every file got a content fingerprint in a signed, append-only log anchored in Bitcoin once a day.
• On 24 October my book went to Zenodo, the open research archive run by CERN, with a DOI, an open licence and a statement of exactly how it was made.
• The thread: proof does not make you right. It makes you checkable. For a one-person lab that partners with AI, checkable is the only kind of credibility that scales.

The before: careful, and still just my word #

On 26 April 2026 I added three new threat-intelligence dossiers to my website and rewrote them the same day into deeper investigations: a 30-node attack network on one cloud provider, a 31-instance fingerprinting campaign on another, a worm traced through a chain of shell companies. The stats banner on the page said 347,000 events, 3,282 attacking IPs, 37 days of observation.

The method was careful. The weakness was structural. A reader could see a table of IPs and a confident conclusion, and they had exactly two choices: trust me, or not. Nothing on the page let them check that the data behind the report was the data I really had, or that I had not edited it last week to fit a better story.

There was a second weakness, and I say it plainly on my own site: a lot of that text is written by AI agents from the lab’s own data, then reviewed by me. That is not a secret. It is also exactly the situation where a reader is right to be suspicious. AI writes confidently. So do people who are wrong.

And the readers were changing. Threat intelligence gets copied, scraped and summarised, more and more by machines. Whatever I wrote would be repeated by systems that cannot ask me a follow-up question.

If you have ever had something you wrote quoted back to you, slightly wrong, with your name on it, you know the small cold feeling. Now imagine it happening at machine scale, without you ever seeing it.

Step one: sealing the reports #

On the evening of 19 July 2026, after a long day of security review, I designed, built and deployed the attestation system in one session. A dedicated signing key, Ed25519, with three backup copies, one of them on separate storage. A transparency-log-backed store. A service that seals every dossier on publish and on every correction. And a verification page on every report that runs in the reader’s own browser, using the browser’s built-in cryptography, with nothing to install and nothing to trust on my side.

By the end of that session, 630 dossiers were sealed and live. While doing it, the reconciliation found ten reports with problems, including operator IPs and mislabelled concepts, and fixed them before they were sealed. The act of preparing proof found errors that months of reading had not.

At 23:12 the same night the second layer went live: OpenTimestamps, which anchors a hash in the Bitcoin blockchain through public calendar servers. The record notes 636 anchors backfilled and 699 pages republished. Before the night was over, the last gaps were closed: 699 of 699 published dossiers sealed.

It was not clean. The first time the browser verifier ran against real reports, it called three of them TAMPERED. Nobody had touched them. Python had written the number as 90.0, JavaScript as 90, and the hashes differed. Worse, I found a verifier path that would have shown a green “authentic” badge for a report whose content had been swapped, because it compared two fields from the same bundle instead of recomputing one from the signed data. Both stories, with the fixes, are in the post on signing threat intelligence.

The rule that came out of that week is the one I care about most: corrections go into the investigation first, then the report is resealed, so the signature always covers the corrected version. A seal is not a promise that I was right. It is a promise that you can see what I said, and when, and what I changed.

Today the site lists 817 published dossiers. Every one carries a seal.

Step two: proof for a library #

The library was the harder case. A threat report is one document I wrote. A library is a hundred thousand documents other people wrote, which I collected, reorganised and fed to AI systems that quote them.

On 5 October 2026 I wrote the goal into my record in one line: verifiable content for any AI system. When a model quotes a page from my library, a reader, or another model, should be able to check that the page exists, that it is byte-for-byte the file I held, and that I held it on a given date, without trusting me or my server.

The design, decided that morning and built the same day:

• every file gets an IPFS content ID, a plain SHA-256 and its size, computed with a reproducible profile so any tool gets the same answer;
• the fingerprint belongs to the file record, not the path, so moving a book to a better shelf never changes it;
• metadata is excluded, so titles and authors can be corrected forever without touching the proof;
• fingerprints become leaves of an RFC 9162 Merkle log, cut into a new epoch every day, signed with the library’s own key and anchored in Bitcoin.

The key that signs it was pinned on the first epoch at 18:28 UTC on 5 October. The next day a slow maintenance job held a database transaction open, a startup migration queued behind it, and the catalogue went down for 13 minutes. Proof systems are still systems; they fail in boring ways. The full design and that outage are in the provenance ledger post.

Since then the log has never had a failed epoch. 15 epochs, 331,631 leaves, all anchored, zero mismatches when the node re-checks the stored content.

The technical heart: what each layer proves #

People hear “Bitcoin” and “Merkle tree” and either glaze over or get excited for the wrong reasons. Here is what each layer actually buys, in plain terms, because none of them is enough alone.

A hash proves sameness. If your copy of a file has the same SHA-256 as the one in my log, it is the same file, bit for bit:

sha256sum <file>

A Merkle tree proves membership without publishing everything. The log is a tree of hashes. To show that one file is in it, I give you a short path of sibling hashes from that leaf to the root, a few hundred bytes even for hundreds of thousands of files. For dossiers, the same trick lets sensitive parts stay sealed: provable, but not published.

A consistency proof proves I did not rewrite history. Each new epoch must contain every earlier one unchanged. If I deleted or altered an old leaf, the proof between epochs would fail.

A signature proves who. The root of each epoch is signed with a key whose public half is published. Anyone can verify; only the holder of the private key can sign.

A timestamp proves when, against a clock I do not control. The hash of each signed root goes into a Bitcoin block through OpenTimestamps. I can sign anything with any date I like. I cannot get it into a block that was mined last week.

A persistent identifier proves where, beyond my lifetime. This is the layer I added last, and the one that has nothing to do with cryptography.

Step three: a book with a DOI #

On 23 October 2026 I published a book on my personal blog: Religions, Cults and Power: From Zoroaster and Mithra to the Singularity, a 174-chapter study drawn from my library, every claim cited to a work in the catalogue. How it was written is its own story, the next one in this series. Here I want to tell why it went somewhere else as well.

A blog post can disappear. A domain can lapse. A machine in an apartment can be wiped by a test, as mine once was. Everything I had built so far proved what I held, as long as I was around to serve the proof.

So on 24 October the book went to Zenodo, the open repository operated by CERN, as Revision 2: 1,542 pages, built from the book’s own LaTeX source. Zenodo assigns a DOI, a Digital Object Identifier, the same kind of permanent link academic papers use. Mine is 10.5281/zenodo.23623219, and a concept DOI above it always points to the newest revision.

Three details of that day matter:

• The DOI is permanent. My own preparation notes say it plainly: Zenodo mints it the moment you press Publish, and it cannot be deleted afterwards, only versioned. That is the point, and it raises the stakes of every sentence in the record. There is no “unpublish” for a mistake.
• The description says how it was made. The note I wrote next to the form field reads: edit the last sentence to say exactly how the text was produced, because an honest statement here protects the DOI’s credibility later. The copyright page of the PDF says the same: drafted with AI assistance from the library and its offline reference shelf, and reviewed by the author.
• The licence matches the sources. About a third of the book is attributed quotation, and some of it comes from Wikipedia under CC BY-SA. So the book is CC BY-SA 4.0, printed on the copyright page and set in the Zenodo record, so the file and the archive agree.

One small comedy: Zenodo’s form rejected my ORCID researcher ID because it starts with 0009, a newer range its validator did not recognise. The fix was to publish without it and attach the work from the ORCID side. Even permanence has a support queue.

And the loop closed. The book went back into the library as a catalogue work. Its first revision’s fingerprint is in the ledger, anchored in Bitcoin block 972,852. The book cites the library by catalogue number; the library proves the book.

The after: what proof changed #

It changed what I am willing to publish. If I cannot seal it, I think twice about whether I can stand behind it. Preparing a seal found ten flawed reports on the first night. That alone was worth the work.

It changed how I correct. A correction is no longer an edit; it is a new signed version, with the old one still provable. Being wrong in public is visible, and that is fine. Being wrong silently is no longer possible, and that is better.

It changed how I think about AI writing. Agents draft most of the dossiers and drafted most of the book. The proof does not care who typed the words. It records what was published, when, and from which data, and it makes the review step accountable: my name on a signed, timestamped artifact is a claim that I checked it.

It cost things. Weeks of work on canonical JSON and verifiers that are harder to get right than the cryptography. A daily job that will run for as long as the library exists. And a permanent record of my mistakes in a place I cannot edit.

There is something I have not solved. All of this proves integrity and time. None of it proves truth. A sealed report can still contain a wrong attribution; it will just be a provably, timestamped wrong attribution. The answer to that is not more cryptography. It is the method on the page, the sources linked, and the willingness to publish the correction when someone finds the error.

What changed #

• Reports went from “trust me” to “check me”: sealed, anchored, verifiable in the browser.
• The library went from files I say are real to files anyone can match against a signed log.
• The book went from a blog post to a permanent, citable record with an honest colophon.
• Corrections became versions, not edits.

Questions people ask me #

Why use Bitcoin at all? Is this a crypto project? #

No coins are involved and nothing is bought or sold. OpenTimestamps puts a single hash into a Bitcoin transaction through free public calendars, batching thousands of users together. Bitcoin is used only as a public clock that nobody, including me, can rewind.

Can a reader verify a dossier or a library file without trusting your server? #

Yes. The dossier verify page runs in the reader’s browser with its built-in cryptography. For the library, a small verification script and the published ledger let anyone check a file offline: hash it, check the inclusion proof against a signed root, and check that root’s timestamp in Bitcoin.

What does a DOI give a self-published book? #

A permanent, citable identifier that resolves even if my site disappears, an archive copy held by an institution that is not me, and indexing by academic search engines. It does not peer-review the book. It makes the book findable and the version exact.

Does signing AI-written content make it trustworthy? #

No, and nobody should claim it does. Signing makes it accountable: anyone can see exactly what was published, when, and later whether it changed. Trust still comes from the method, the sources, and an honest statement of how the text was produced.

Closing #

I started publishing because every attack on my lab can make others safer, but only if they can use what I found. I started signing because I realised that “I saw it” is not evidence when the reader is a stranger, or a machine.

One person in one apartment cannot be a trusted institution. But he can make every claim checkable, timestamp it against a clock no one controls, and leave a permanent copy with someone who will outlast him. That turns out to be enough to be taken seriously, and, more importantly, enough to be corrected.