Grin has never had a company behind it, a marketing department or an official historian. Almost everything that happened to the project between 2018 and 2025 happened in public on its forum: the emission debate, the scheduled hard forks, the founder’s disappearance, the day somebody tried to create coins out of nothing. That is a wonderful record and a terrible way to read one. So in January 2026 I compiled the forum into a short book, Grin: A Brief Story, using the Discourse API and Claude Code. This is how I did it, where the judgement had to come from, and what the community caught that the model missed.
I’m Wayne George, a software engineer in London. I wrote an open-source Grin wallet for iOS, so this was a project I cared about rather than a demo, and you can read the result at /grin-a-brief-story.html. The grin-book repository on GitHub holds the finished book as Markdown, EPUB and HTML, the ten chapters beside the raw source files they were drafted from, the two scoring files, the attribution notice and the script that builds the EPUB. It does not hold the fetching and scoring code itself, so what follows is a description of the method rather than a tour of the repository.
Why a book
Grin is the first implementation of the Mimblewimble protocol (I have written a plain-English explainer if the name means nothing to you). The whitepaper was shared in the #bitcoin-wizards IRC channel on 1 August 2016 by a pseudonymous user; the genesis block was mined on 15 January 2019; and Ignotus Peverell, the developer who started the project, “disappeared and has yet to return”. The community has run it ever since.
Projects like that do not write their own histories. When contributors drift away the context goes with them, leaving thousands of threads that only make sense if you were there. I wanted one narrative someone could read on a Kindle in an evening.
My first attempt was a retrieval system: index every post, then ask it questions. It worked, but it only ever answered what I thought to ask. A book forces a decision about what matters, and that decision turned out to be the hard part.
Getting the posts out of Discourse
The forum runs on Discourse, which describes itself plainly: “Discourse is backed by a complete JSON api. Anything you can do on the site you can also do using the JSON api.” Every topic page has a JSON twin — append .json to its URL and the posts come back as structured data, with no key needed for public content.
With Claude Code I wrote a fetcher that walked the topic listings year by year, pulled every post for every topic and saved one JSON file per topic in a folder per year. That gave me 2,930 topics from 2018 to 2025 and 33,658 posts between them. The launch year, 2019, was by far the loudest, with 1,064 topics on its own. Those fetched files are not in the repository, but the scoring output is, and it still records the per-year path each topic was saved to.
Scoring topics for significance
Thirty-three thousand posts will not fit in any model’s working memory, and they should not: most are price chatter, mining questions and broken wallets. I needed a way to find the threads where something actually happened.
The scoring pass gives each topic a single number, and the file it writes records what went into it: views, replies and likes; which of the project’s core contributors posted; and keyword matches across nine themes — wallets, privacy, governance, proof-of-work, launch, emission, the protocol itself, hard forks and conferences. The full output is all_topic_scores.json. The 150 topics that made the cut are in selected_topics.json, spread across ten chapters running from “MimbleWimble Origins” to “Legacy & Future”.
It is worth being honest about how crude this is. The highest-scoring topic in the whole forum is a 1,061-post market shitposting thread, which matched none of the nine themes and got there on engagement alone. Engagement measures heat, not importance, and no formula was going to know that a quiet two-post announcement mattered more than a hundred-post argument. That is a judgement, and judgement is exactly the thing you cannot outsource.
Drafting with Claude Code
For each of the ten chapters the pipeline produced a raw file: the selected topics in date order, each under a header giving the forum link and its score, with every post reproduced under its author and date. The raw material for the governance chapter runs to about 300 KB; the finished chapter is 6 KB.
Claude Code is Anthropic’s agentic coding tool, which by its own documentation “reads your codebase, edits files, runs commands, and integrates with your development tools”. I used it with Claude Opus 4.5, released two months earlier. Every chapter had the same job to do: turn the raw file into narrative non-fiction, quote the forum verbatim where the original words beat a paraphrase, and credit every quote to the username that wrote it. The raw files sit beside the final chapters in the repository (01_raw.md next to 01_final.md, and so on), so anyone can check a claim against its source.
I also asked for the book to be concise, and that is where the trouble started. As I put it on the forum afterwards: “I did ask for it to make it concise and it clearly didn’t make the best choices in terms of what to leave out.” My first pass had no mention of the two anonymous 50 BTC coinbase donations to the project, which anyone around at the time would remember. I put them back before publishing. I did not catch everything, as you will see.
Building the EPUB
The book had to work on an e-reader, so create_epub.py stitches the ten final chapters into an EPUB with the Python ebooklib library. It converts the Markdown to HTML with a deliberately small set of regular expressions, adds an introduction page and the attribution notice, applies some Kindle-friendly CSS and writes out the file. I wrote it with Claude Code. It is 247 lines of boring, well-specified plumbing: the kind of work an AI assistant is unambiguously good at, and the kind I no longer want to type myself.
Licensing: the forum decided for me
Before publishing, I read the forum’s terms. The Grin forum’s Terms of Service state that “User contributions are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.” That licence carries through to anything built on the posts, so the book is CC BY-NC-SA 3.0 too. In plain terms: anyone may share and adapt it; they must give credit; they may not use it commercially; and anything built from it must carry the same licence.
That suits the project. The book cannot be sold, by me or by anyone else, and the attribution notice on its last page sets out how quotes are credited — beside the excerpt, naming the author’s username, the source thread and a link to it, and at section, chapter or appendix level where material has been summarised. The original words still belong to the forum’s contributors.
What the community caught
I posted the book to the forum on 27 January 2026 and invited forks and pull requests. The thread turned into the best review process I could have asked for.
John Tromp, who designed the Cuckoo Cycle proof-of-work that Grin is built on, replied within two hours, generous about the writing and precise about the gaps. Grin’s ASIC-resistant proof-of-work was modified at each of the first three six-monthly hard forks to “interrupt possible ASIC development for it”; the fourth, in January 2021, brought no new algorithm. The book, Tromp wrote, “leaves out mention of the 3rd member of the cuckaroo family. In between cuckarood and cuckarooz there was room for cuckaroom:-)” Cuckaroom was unveiled at GrinCon1 in November 2019 for the second hard fork, and as he put it at the time, its graph “is no longer bipartite, with the ‘M’ standing for ‘Monopartite’”.
He also pointed out, fairly, that the book had cast him as the proof-of-work person when he had “co-architected and worked on several parts of the consensus code besides cuckoo”: the emission, the Merkle Mountain Ranges the chain stores its data in, difficulty adjustment, the transitions between proof-of-work algorithms and the fee system. “I consider myself a core developer as well.” The draft had reduced a core developer to his best-known invention, and I had not noticed.
Two days later another member said the book was missing the inflation bug, “since that also tells something about how the project is run.” They were right. On 18 March 2021 an attacker got a malicious output into block 1,136,081 by exploiting a flaw in the rangeproof verification cache: affected versions would “skip verification of a rangeproof for an output commitment if that rangeproof had recently been verified, even if the earlier verification was for a different output commitment” (Grin security disclosure).
Grin++, the independent C++ implementation, had the validation the Rust node lacked and rejected the block; hotfixes removed the caching, and the attack “was ultimately mitigated with a longer proof-of-work chain with proper validation”. A history of Grin cannot leave out an incident that shows both the risk of hidden amounts and the value of two independent implementations. I added a section on it and pushed the change the same day. The current version covers Cuckaroom properly too.
One more thing came out of the thread. A reader could not reach GitHub from where they were, so I now keep an HTML version on this site, the copy linked above, updated as the book changes.
What AI is good at here, and what it is not
Having done this once, I would split the work three ways.
The mechanical work
The model does this better and faster than I would: fetching thousands of topics, structuring them, writing the scoring and EPUB scripts, converting formats. There is no reason for a person to type any of that.
The reading
It does this at a scale a person cannot match. Given all 150 selected topics, 10,842 posts between them, it produced a draft with a consistent voice that quotes accurately from the source. By hand I would have skimmed, and missed more than it did.
The judgement
It does not do this, and it does not know that it does not. Told to be concise, it cut things it had no way of weighing. It could not see anything that happened away from the forum: GitHub threads, chat rooms, conference corridors. It tends to reduce a person to the one thing they are best known for, which is how the early draft treated John Tromp. Its prose is confident whether or not the record underneath it is. And the significance score it worked from was my design, with my blind spots built into it.
What fixed those problems was not a better prompt. It was the people who lived the history reading the draft and saying what was wrong, and the forum thread did in two days what no amount of re-running the model would have done. If you try this for your own community, publish early, in the open, under a licence that lets people correct it, and treat the first version as a question rather than an answer.
Where to find it
The book is at /grin-a-brief-story.html, there is an EPUB for e-readers, and the Markdown and the working files are in the repository. It will keep being wrong in places until someone tells me where; pull requests are welcome. If the tooling interests you more than the history, a public data source, a scoring pass, a drafting pass and a person checking the result is the same shape of work I build for clients at Frontier Consulting.