Docs

Building and running Shrike

Build requirements are unchanged from upstream. The one thing to get right is the recursive clone.

Clone #

Clone this repository rather than upstream's, and --recursive matters: the BLAKE2b work lives in the drongo submodule, and a flat clone will not build.

git clone --recursive https://github.com/privkeyio/shrike.git

When updating later:

git pull --recurse-submodules

Requirements #

Java 25 or higher. The release binaries are built with Eclipse Temurin 25.0.2+10; with SDKMAN, sdk env install picks up the right version. On Debian and Ubuntu, packaging also needs:

sudo apt install -y rpm fakeroot binutils

Building the Windows installer additionally needs WiX.

Build #

./gradlew jpackage

On distributions without deb or rpm tooling, such as Arch, skip the installers:

./gradlew jpackage -PskipInstallers=true

Running from source #

From the project directory, with Java 25 or higher installed:

./sparrow

The convenience script in the source tree kept its upstream name, so it is ./sparrow even here. The launcher inside a built or installed package is shrike.

Command line options:

--dir, -d        Path to the home folder
--help, -h       Show usage
--level, -l      Log level: ERROR, WARN, INFO, DEBUG, TRACE
--network, -n    mainnet, testnet, testnet4, regtest or signet

Note that testnet means testnet3.

Home folder #

Unless -d says otherwise, Shrike keeps its config, log and wallets in ~/.shrike on macOS and Linux, with the other networks in subfolders. It is a separate location from Sparrow's, so the two installations never share state. On macOS and Linux the XDG base directory specification is supported as an opt-in, resolved per category: where the corresponding directory already exists it is used, otherwise the home folder is. Passing -d disables XDG resolution entirely and puts everything in the folder you name.

Reproducible builds #

The release binaries are reproducible, before codesigning and installer packaging. The procedure is kept with the code, in docs/reproducible.md, along with the two regtest walkthroughs that verify the proof of work and the signature hash against a live forked node.