A $TUNA miner, written in Go
Bluefin is self-contained and runs with no external dependencies. You can run it via the Docker images or binaries from the releases page.
Bluefin is designed to take its configuration from environment variables. All examples below show running the bluefin binary directly from the shell and will need to be adapted for use with Docker.
When run with no configuration, bluefin defaults to mining TUNA v1 on mainnet. It will generate a new
wallet and write the seed phrase to the seed.txt file in the current directory.
$ ./bluefin
...
{"level":"info","timestamp":"2024-07-04T20:13:53-05:00","caller":"wallet/wallet.go:62","msg":"wrote generated mnemonic to seed.txt"}
{"level":"info","timestamp":"2024-07-04T20:13:53-05:00","caller":"bluefin/main.go:73","msg":"loaded mnemonic for address: addr1..."}
{"level":"info","timestamp":"2024-07-04T20:13:53-05:00","caller":"bluefin/main.go:79","msg":"starting indexer on mainnet"}
You can use the NETWORK and PROFILE environment variables to change the mode that bluefin operates in.
For example, to mine TUNA v2 on preview:
$ NETWORK=preview PROFILE=tuna-v2 ./bluefin
If you want to provide your own wallet seed phrase, you can set the MNEMONIC environment variable or create the seed.txt file before
running bluefin.
If allowing bluefin to generate a new wallet, you will need to seed the wallet with some initial funds using the wallet address logged at startup. If the wallet already exists, you may need to send funds back to your own wallet so that they're visible to bluefin. The wallet will need at least 2 available UTxOs, one to cover TX fees, and another of at least 5 (t)ADA to use as collateral.
By default, bluefin will use the NtN (node-to-node) TxSubmission protocol to submit transactions directly to the Cardano network.
This method has the downside of not providing any feedback if a transaction fails. You can use the SUBMIT_URL environment variable
to specify the URL for a submit API to use instead, which will provide feedback about any transaction validation issues.
Bluefin stores its local data in .bluefin/ in the current directory. If you run into a problem that requires clearing the data, you can
delete this data and bluefin will re-sync from scratch.
This requires Go 1.19 or better is installed. You also need make.
# Build
make
# Run
./bluefinYou can also run the code without building a binary, first
go run ./cmd/bluefinBluefin can optionally mine on a GPU using OpenCL. The OpenCL backend
is gated behind the opencl Go build tag so that the default,
pure-Go, CGO_ENABLED=0 build keeps working everywhere.
- A C toolchain (
build-essentialon Debian/Ubuntu). - OpenCL headers (
opencl-headerson Debian/Ubuntu). - An OpenCL ICD loader development package
(
ocl-icd-opencl-devon Debian/Ubuntu).
make build-openclThis is equivalent to:
CGO_ENABLED=1 go build -tags opencl -o bluefin ./cmd/bluefinYou need a vendor OpenCL ICD installed for your GPU at runtime:
- NVIDIA:
nvidia-opencl-icd(ships with the NVIDIA proprietary driver). - AMD:
mesa-opencl-icd(open-source) or AMDGPU-PRO/ROCm OpenCL. - Intel:
intel-opencl-icd/ NEO.
You can verify what OpenCL devices are visible with clinfo.
Select the OpenCL backend at runtime via the MINER_BACKEND env var:
MINER_BACKEND=opencl ./bluefinOther relevant env vars:
| Variable | Description | Default |
|---|---|---|
MINER_BACKEND |
Mining backend: cpu or opencl. |
cpu |
MINER_GPU_DEVICE |
Index of the GPU to use (0 = first). | 0 |
MINER_GPU_BATCH_SIZE |
Nonces per kernel dispatch. 0 = sensible default. |
0 |
If MINER_BACKEND=opencl is requested on a binary built without the
opencl tag, bluefin will exit with a clear error explaining how to
rebuild with GPU support.
Note: A CUDA backend is planned as a follow-up; the GPU backend framework was designed so that an additional backend can be slotted in behind a
cudabuild tag without further refactoring.
We're looking for people to join this project and help get it off the ground.
Discussion is on Discord at https://discord.gg/5fPRZnX4qW
