gocoin splits a Bitcoin node from a cold storage wallet

A node that keeps every UTXO in memory

gocoin is a full Bitcoin solution written in Go, and the architecture has one dominant idea: performance for the node, cold storage security for the wallet. The client, described as the p2p node, is an application independent from the wallet. It keeps the entire UTXO set in RAM, which the README says gives instant access to all its records and, as a consequence, an extraordinary blockchain processing performance.

Holding the unspent transaction output set in memory is a design decision with an obvious cost: the node cannot run on a small machine. The hardware section asks for a 64-bit architecture operating system and a Go compiler, a file system supporting files larger than 4GB, and at least 32GB of system RAM. The rest of the requirements are ordinary: any target OS supported by your Go compiler, with Windows, Linux, macOS and Free BSD listed as currently supported targets.

The wallet side makes the opposite trade. It is designed to be used offline, and it is deterministic and password seeded, so as long as you remember the password you do not need any backups. The wallet can be used without the client at all, using the provided balio tool instead. That separation is the whole point of the design: the machine that holds keys never needs to be the machine that talks to the network.

Cold storage rules for the wallet machine

The wallet requirements are worth reading as a security checklist, because they are about the machine rather than about the software. Any platform you can make your Go cross compiler build for works, and a Raspberry Pi is given as an example, so the wallet can live on hardware that has no reason to be connected to anything.

The security instructions are explicit about the two ways a wallet host can leak. If there is a swap file, use an encrypted one, because memory that survives a reboot is memory that can outlive the process. And if you decide to store your password in a file, encrypt the disk, in case the machine is stolen. The reasoning is that the wallet's safety depends on the password never leaving the device in a recoverable form, whether through swap or through an unencrypted file.

That matches the deterministic and password seeded design. Because the seed is the password, there is no separate backup to lose, which also means there is no recovery path if the password is forgotten, and no second copy to store somewhere safer. The trade is deliberate and total: convenience of backup in exchange for a single point of failure that is human.

The wallet also expects a real mail workflow, not a toy. A user's mail appears in a spool in their home directory, and the documentation suggests installing mutt on the server, adding set spoolfile="+Inbox" to the ~/.muttrc, and reading mail over an SSH session.

Building the client, the wallet and the tools from source

The build environment needs a recent Go installation, and Git optionally. With those in place the documentation says you should be able to execute go and, if you wanted it, git from a command prompt without specifying full paths. There is no package manager step, no configuration file to write first, and no dependency list beyond what the Go modules resolve; the go.mod in the repository declares module github.com/piotrnar/gocoin and a go directive of 1.18.

Get the sources with:

git clone https://github.com/piotrnar/gocoin.git

If you would rather not use Git, the documentation points to the archive on GitHub and extracting it to a local disk, which produces the same tree.

The client is built by changing into the client/ folder and running:

go build

The wallet is the same procedure in the wallet/ folder, and the tools are per sub-folder inside tools/, where each sub-folder is a separate tool with its own go build. The layout at the top level, with client/, lib/, wallet/, tools/ and version.go, matches that structure: a library package, the node, the wallet, and a set of small utilities.

If you would rather not compile anything, the Releases page has binaries of the client, the wallet and the balio tool for Windows, Linux and macOS, and SourceForge hosts older ones. The documentation warns that the binaries are almost never up to date and strongly encourages building them yourself, which is a rare and useful thing for a project to say about its own release page.

The sync comparison and how it was measured

The README presents a chart of the system memory and time the Gocoin node needs to sync the blockchain up to a given block number, with a comparison against Bitcoin Core 30.2. The chart is an image, so the README does not state figures in text, and the article therefore cannot restate them. What the documentation does state is the method: the data was collected on a Hetzner dedicated server with an Intel i7-7700 CPU, 64GB RAM, two 512GB SSDs and a 1Gbit internet connection, using the default node configuration.

The caveat the author adds is the interesting part. Results may vary by 10 to 20 percent depending on the luck of connecting to good peers. That is a network effect, not a CPU effect, and it means a single run of this kind is a snapshot rather than a specification. The README also points to gocoin.pl for further performance charts.

Read together with the requirement of at least 32GB of RAM, the picture is coherent: a node that wants the whole UTXO set in memory needs a machine with memory to spare, and the comparison is run on a 64GB server, twice the stated floor.

One author, no merged pull requests, custom terms

The development section is unusually direct. Although the project is open source, the author writes that he will not merge in any pull requests, and gives the reason: he wants to stay the explicit author of the software in order to keep full control over its licensing. Missing functionality is handled by describing the need to the author, and anyone who wants their own code in should fork and develop their own repository.

That policy has consequences for adoption. You cannot plan on a feature landing through a community pull request, and the upgrade path is a release from the author, not a merged change from a user. The licensing field on the project listing is marked as Other, a custom licence that GitHub cannot classify, with the actual terms in the LICENSE file at the root of the repository. The repository also carries a todo.txt and a changelog.txt, which is where you would look for what the author is considering and what changed.

Support is also handled personally. The project page at gocoin.pl is the official site and carries the extended documentation including a User Manual, and the README asks people with questions rather than issues to use the contact page instead of the GitHub issue tracker. The project asks supporters to run their own Gocoin node, preferably with TCP port 8333 open to the outside world.

Release cadence and the gap between tags and source

The published releases are 1.11.0 on 2025-11-15, 1.10.4 on 2025-03-23 and 1.10.1 on 2025-03-23. The last push was on 2026-10-10 and the repository is not archived, so work is continuing on master, but the tagged releases run about a year behind the head of the branch, and the two March releases landing on the same day suggests patch releases are produced when needed rather than on a calendar.

For an operator, that gap decides your upgrade policy. A release tag is a known state of the code, and the maintainer explicitly says the binaries are almost never current, so building from a specific tag is the only way to be sure what you are running. If you take master, you are taking whatever the branch contains on the day you build, which for a node that handles your own keys and your own transactions is a different risk profile than taking a tag.

The cost of staying current is also shaped by the split architecture. Updating the node and updating the wallet are separate operations on separate machines, and the wallet's role in the protocol, signing transactions that the node then relays, means the two pieces have to agree on transaction formats and network rules. The documentation does not describe a compatibility matrix between client and wallet versions, so the safe assumption is that you update both from the same tag.

Where gocoin is the wrong choice

The requirements decide this for a lot of people. A node that keeps the entire UTXO set in RAM and asks for at least 32GB of system RAM, plus a file system handling files larger than 4GB, does not fit a cheap virtual host or a small NAS. The project targets a dedicated server, and the performance comparison was run on one. If your constraint is a 2GB VPS, gocoin is the wrong tool and the alternative is a client built around a disk backed database, which is the approach gocoin deliberately does not take.

The second wrong fit is organisational. A project where the author will not merge pull requests, licenses under custom terms and provides support through a personal contact page is a dependency on one person. That is a legitimate model for a specialist tool and a poor foundation for something your company depends on for a decade. Forking is the documented escape route, and it is the honest answer: if you need your own changes, that is the path, with the licensing terms as the condition.

The third case is a convenience user. A deterministic, password seeded offline wallet with no backup requirement is elegant for a single user who understands the model, and hostile to anyone who expects a recovery phrase in a drawer, a second device to restore from, or a web interface. Combined with the absence of a graphical mail client, gocoin is a toolkit for people who are comfortable in a terminal and running their own node.

Editorial conclusion

gocoin suits a technically confident operator who wants a Go based Bitcoin node and a wallet that never touches the network, and who can afford 32GB of RAM and a wide margin of disk. It is the wrong tool for a shared hosting box, for a team that expects to contribute patches upstream, or for anyone who needs a single all in one binary. Verify first that your file system supports files larger than 4GB, that the Go toolchain in use can build the client and wallet folders as the README describes, and that the LICENSE file grants you the rights you need, since the project is published under custom terms rather than a standard open source licence.

Frequently asked questions

Official sources

1. Issues
2. piotrnar/gocoin on GitHub
3. README
4. Releases