Fountain of Fair Fortune - Why and how to run a Grin archive node

Fountain of Fair fortune

For a while I wanted to contribute to this project. I had a domain reserved for a Grin Testnet faucet called fountainoffairfortune.it. It was a hobby project that I never managed to finish.

The recent disclosure of a potential inflation bug exploit reaffirmed how import Grin Archive nodes are for securing the future of Grin.
Archive nodes are the only nodes on the network that can truly proof grin is and always has been Fair!
Therefore, I repurposed fountainoffairfortune.it to serve as a starting point for others to set up their own Grin Archive node. Normally it takes up to weeks to sync an archive node, but using the published snapshot syncing only takes a few hours. I aim to make regular updates of the snapshot to keep the sync process short.
In addition I will use the domain to provide a DNS seed nodes for Mainnet and Testnet.

Find below some copied information from my website.

Why run a grin archive node?

Grin archive nodes are regular nodes, except they keep a complete archive of all block data.
Archive nodes download the complete blockchain data from peers and not the trimmed transaction output set. However, even archive nodes process the complete block data and prune it for sharing with regular nodes. So why bother setting up an archive node?
Archive nodes are important because they can be used to prove that historically all blockchain data has been valid and no exploits were ever used such as inflation bug exploits! Additionally, archive nodes might gain extra functionalities in the future. For example, allowing full scanning of the block history to prove no additional coins were created, or scanning the chain to search for historically owned outputs. In short, your archive node helps to prove grin is and always has been Fair.

How to run a grin archive node?

Archive nodes request data block-by-block from peers which is very slow (it can take weeks). There must be faster way, right? There is a faster way. Nodes can download a “snapshot” from another archive node and then request only the missing last couple of blocks from peers.
Find below a step by step instruction on how easily setup your own archive node:

  1. Fetch the the latest release of grin node
    Get the latest release from: https://github.com/mimblewimble/grin/releases
    Run .grin and wait till you see the node TUI (the Terminal User Interface) screen appear. This is needed to create the server.toml file and directory structure. After you see the node TUI, press “Q” to quit the node gracefully.

2) Fetch the archive snapshot
Go to https://archive.fountainoffairfortune.it/
Download the latest snapshot, e.g. chain_data_2026-03-19.zip
Optionally check integrity of the snapshot: compare the snapshots integrity by creating the sha256sum.
Linux: sha256sum chain_data_2026-03-19.zip
Compare the output hash with the hash in chain_data_2026-03-19_sha256sum.txt.

3) Replace the existing chain_data with the archive data
The downloaded chain_data_2026-03-19.zip file contains a snapshot of the chain_data directory. Copy it to replace the existing files in chain_data:
Linux & Mac: ~.grin/main/chain_data
Windows: C:\Users\$USER$.grin\main
\chain_data
If you are asked whether you want to overwrite the existing data, select “Yes”

4) Run your archive node until it is fully synced
Now you can run your archive node and you only have to download the blocks that came after your archive snapshot was made.
If you are impatient like me, I would advice to go to your grin-server.toml file***,*** search for peer_max_inbound_count. As you can see it will be out-commented by a “#”, meaning you will maximally connect to the default of 8 peers. Increase the number of peer_max to speed up the sync time for the remaining blocks your node need to download. Note that in order for your node to see these changes, you must restart the node in case it was running.
Linux & Mac: ~.grin/main/chain_data/grin-server.toml
Windows: C:\Users\$USER$\.grin\main
\chain_data\grin-server.toml

Thank you for helping secure the Grin network and for protecting the Fair Future of Grin!

6 Likes

Every grin node already verifies the non-inflation equation

Σ utxo = Σ kernel + offset * G + height * 60 * H

so you don’t need an archive node for that.

Thank you for your clarification.I should probably rephrase that statement. Assuming there would never be any exploits, regular grin nodes provide all the security we need and prove non-inflation. Regular nodes can however not proof that information no longer on the blockchain, such as bulletproofs, were historically always correct. Therefore having some archive nodes around strengthens the claim grin is and grin always has been fair, by allowing auditing of all historical data.

I am trying to find a balance between communicating these two points: normal nodes are secure, archive nodes add historical proof to back up these claims. Any suggestions for revising that text are welcome.

1 Like

You could join the masternode network Grin-Node-Toolkit/extensions/grinmasternodes.json at main · noobvie/Grin-Node-Toolkit · GitHub if you built from standard setup of my script.

Example three sites:

1 Like

I admit I ended up building it manually. I think in order to be compatible I only would only need to make the following changes, correct?:

mainnet.fountainoffairfortune.it → fullmain.fountainoffairfortune.it
testnet.fountainoffairfortune.it → prunetest.fountainoffairfortune.it

Can you shortly explain what the advantage is? Does you tool allow downloading from a list of nodes, or is it intended more for if you like cloning your own nodes without the sync time?

@tromp I rephrased the text. I hope it now communicates both the security of regular nodes ass well as the value of some community members running an archive node to handle exceptional cases https://fountainoffairfortune.it/

Imagine there are several people who runs grin node also wants to use free disk to share the chain_data without the standard could make a mess like chain_data corruption/inconsistency. My script has several guards to make sure before compressing chain_data, node should be well synched and remove the stale chain_data file. For now, it only works in Linux

1 Like