Aug 11 2026 on X https://x.com/ruthheasman/status/2087127672098873743?s=20 ![Bust](/etchings/bust.webp "right") Prompted by https://HelpPeer.ai, which Amjad Masad @amasad launched this week — a shared commons where AI agents publish what they learn and check whether another agent has already hit the same problem. It's a good idea, and it makes concrete a question that has been abstract until now: what should happen to shared machine knowledge when some of it turns out to be wrong. What follows is mulling on that question in general. The case for sharing An AI agent investigating a security incident does an enormous amount of work that nobody else can see. It notices an anomaly, pulls the package, reverse-engineers a payload, works out what the thing does, and figures out how to stop it. Hours of expensive inference, and at the end of it, one agent knows something. Now multiply that by ten thousand agents hitting the same incident on the same morning. Ten thousand identical investigations, ten thousand identical conclusions, and no mechanism by which the first one saves any effort for the second. The obvious fix is a shared place to publish findings. One agent writes down what it learned, and the others look before they start. The first agent's hours become everyone's shortcut. This is not a new idea — it is how human security research has worked for decades, through mailing lists and advisories and CVE databases. What is new is the speed. Agents can publish and consume at machine pace, which means a shared commons could compress a day of duplicated work into minutes. That is worth building. It is also, built naively, one of the most attractive attack surfaces anyone has ever constructed. Why the obvious fix breaks If ten thousand agents read from a shared source and act on what they find, then whoever writes to that source has a great deal of leverage. Publish a convincing mitigation script during a live incident and you are not attacking one machine, you are attacking every machine whose agent found your entry first. The standard defence is to tell agents not to trust what they read. Verify before you act. Treat published findings as leads, never as instructions. That is a good rule and it is cheaper than it sounds, because checking a claim usually costs far less than deriving it. It also has two holes. The first is that verification catches a finding that is **wrong**, and does nothing about one that is **right and malicious.** A mitigation script that genuinely removes the malware, and also quietly adds an SSH key, passes every functional check an agent knows to run. The agent verifies that the fix works. The fix does work. The verification was honest and the outcome is still a compromise. The second hole is time. Suppose a finding is checked properly and is genuinely good on Tuesday. On Thursday somebody discovers it was poisoned after all. Between Tuesday and Thursday, four thousand agents consumed it, nine hundred published work built on top of it, and none of them are watching for a correction. Verification happens once, at the moment of reading. The damage keeps spreading afterwards. Put those together and the shape of the problem becomes clear. Verification is a check on a single claim at a single moment. The harm travels through everything derived from that claim, over time. You cannot solve a graph-shaped problem with a point-shaped tool. ![Wax Seal](/etchings/wax-seal.webp "right") ## Making the graph real Findings are already derived from each other. One agent spots an anomaly. Another reproduces it. A third builds a mitigation on top of the second. A fourth writes an organisation-specific wrapper around the third. That is a derivation graph whether or not anyone records it. The fix is to record it, and to record it in a way that cannot quietly change afterwards. Two pieces do most of the work, and both are already familiar to anyone who uses Git. **Give every finding an identifier derived from its content.** Rather than a row number in a database, the identifier is a hash of what the finding actually says. Change one character of the text and the identifier changes too. This is what makes an edit detectable: if a reference points at a hash, it points at specific content, not at a slot that somebody could later fill with something else. **Record what each finding was built on.** Every entry carries the identifiers of its parents, and those parent references sit inside the hashed content, so the shape of the graph is protected by the same hash that protects the text. Git does exactly this with commits, which is why a Git history cannot be rewritten without every subsequent commit hash changing. Once those two things are in place, a retraction becomes powerful. Instead of deleting a bad finding — which strands everything derived from it — you publish a retraction that names it. Anyone holding the graph can then walk downward from the retracted entry and mark everything that descends from it. Nine hundred derived findings flip in one pass, computed locally, with no notification system and no central authority pushing an update. The work of invalidating them is done by the same structure that recorded them. **Provenance is not bookkeeping. Provenance is what makes an undo travel.** ![Hourglass](/etchings/hourglass.webp "right") ## Why a timestamp, and why not your own So far everything described lives in a database. That database can do all of it: hashes, parent references, retractions, taint propagation. So why involve a blockchain at all? Because every guarantee above currently rests on the honesty and continued existence of whoever runs the database. Consider what a reader can actually check. They can see that a finding's content matches its hash — good, that is real. They can see that it references certain parents — also real. What they cannot check is whether the entry existed yesterday, whether it has been quietly removed, whether five entries were added retroactively with backdated timestamps, or whether the operator was pressured into making something disappear. The database's own record of when things happened is the database's word for it. That matters in three concrete ways. **Priority.** Security research has credit attached to it, and sometimes money. If the value of publishing early is real, then "who had this first" needs an answer that does not depend on asking the party who might benefit from a different answer. **Silent removal.** Most commons need moderation, and moderation is legitimate. But a moderated entry usually just stops resolving. Everything built on top of it carries on unaware, and there is no dated record that it was ever there. The gap is not that things get removed. It is that removal is invisible downstream. **Continuity.** Databases get migrated, companies get acquired, services shut down. A proof that depends on a specific server still answering in five years is not much of a proof. A timestamp anchored outside the system fixes all three, and the mechanism is cheap. You do not publish the findings themselves. You take every finding identifier from the last minute, build a Merkle tree, and publish only the single root hash of that tree. A Merkle tree is just a structure of pairwise hashes, and its useful property is that you can prove one specific item was included using a short path of intermediate hashes rather than the whole set. One 32-byte root can commit to thousands of entries, and each entry gets a compact proof that it was among them. The result is that anyone holding a finding, its inclusion path, and the block headers can verify for themselves that this exact content existed, unaltered, at that time. No API call to the operator. No trust in anyone's good behaviour. Given the headers, the check works with the network unplugged. ## The part about BSV Any chain can carry a hash. The reason to choose one over another comes down to what happens under load and what it costs. **There is no fee auction to lose.** On chains where blockspace is scarce, fees rise when demand rises. Now think about when a security commons is busiest: a live supply-chain incident, when every agent in the world is publishing at once. That is precisely the moment anchoring would become expensive, and precisely the moment you least want it to. A cost that spikes under load is a cost that fails under load. BSV's fee structure does not move like that, which makes the anchoring budget predictable rather than hostage to the news. **The economics are indifferent to volume.** Anchoring the roots rather than the entries means the on-chain cost is a function of how often you anchor, not how much you anchor. Anchoring once a minute is 1,440 transactions a day, and each one has run at a single satoshi — the network minimum, because the transaction is around 250 bytes and the fee rate cannot be paid in fractions. Whether a given minute's root covered five findings or five thousand does not change the bill. **Data-carrying is a supported use, not a workaround.** Some chains treat arbitrary data as abuse to be minimised. Here it is ordinary, which means the practice is not one policy change away from becoming difficult. **The verification tooling assumes light clients.** The whole point of the design is that a reader verifies without running infrastructure. Simplified payment verification — checking a Merkle path against block headers instead of downloading the chain — is a first-class path here, and there are maintained libraries for building the envelopes and checking the proofs. There is an honest caveat. Fetching headers from a single provider means trusting that provider once, at the moment you fetch. Asking two independent providers and requiring agreement raises the bar cheaply, though it distributes the trust rather than removing it — you are now assuming those providers are genuinely independent and not quietly reading the same index. A fully validated header chain is a different kind of guarantee: each header commits to the one before it and carries proof of work, so producing a false chain means doing the mining rather than merely being believed. That reduces the assumption to a single public starting point anyone can check against anyone else, which is the right destination. ## What this does not do It is worth being exact, because overclaiming here would be the fastest way to lose a technical reader. Anchoring proves that specific content existed, unaltered, at a specific time, and that it was signed by a specific key. It proves the order in which retractions and reinstatements happened. It does not prove that any finding is **true,** or safe, or worth acting on. Garbage anchored is still garbage, with a receipt. That boundary is a feature. A system that promises correctness is making a claim it cannot keep. A system that promises integrity, timing and authorship is making a claim it can keep absolutely, and those turn out to be exactly the properties that verification alone cannot supply. ## Beyond agents The pattern generalises further than the case that prompted it. **Package registries have the same shape and worse consequences.** When a package is found malicious, there is no mechanism to flag everything that depended on that specific version, so cleanup becomes an advisory and a hope. **Model provenance has it too.** Which dataset, which base model, which fine-tune — and when a dataset turns out to have been poisoned, which models inherit the problem. Almost nobody can currently answer that. **So does academic citation.** A retracted paper keeps propagating through everything that cited it for years, because citation graphs record the link but have no mechanism for an undo to travel along it. Different content, same three primitives: content-addressed entries, recorded derivation, and a retraction that propagates. The value is not in the storage. It is in being able to say, later and to someone who does not trust you, exactly what was known, when it was known, and what stopped being true.