> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Bitcoin

> Bitcoin Core (bitcoind) — networks, resource defaults, and config overrides

A Bitcoin node runs a single `bitcoind` process. You pick the network, the client version, and (optionally) a few tuning keys in the deploy wizard; everything else — data directory, RPC and P2P bindings, ports, and RPC credentials — is managed for you. The node ships with a full transaction index (`txindex`) enabled, so address and transaction lookups work out of the box.

Supported networks: **mainnet** and **signet**. The client is **bitcoind**, with versions `28.1`, `28.0`, and `27.0` offered in the wizard. The wizard only shows the networks and versions the chosen executor declares, so your options depend on where you deploy.

## Networks and resources

Defaults are pre-filled in the deploy wizard. Lower them only if you know your workload fits — an under-resourced node syncs slowly or stalls.

| Network   | CPU     | RAM   | Disk     |
| --------- | ------- | ----- | -------- |
| `mainnet` | 2 cores | 4 GiB | 1200 GiB |
| `signet`  | 1 core  | 4 GiB | 100 GiB  |

Signet is tiny — use it for a quick smoke test before committing mainnet-sized storage.

## RPC access

RPC access goes through the endpoint Novacula exposes for the node — see [RPC exposure](/docs/nodes/rpc-exposure) for the modes. The node binds the right RPC port per network for you (`8332` on mainnet, `38332` on signet).

A Bitcoin node's RPC authentication is **not optional** — `bitcoind` rejects any unauthenticated call and gives no way to turn auth off. Novacula provisions the same built-in credentials for every Bitcoin node — username `nvcl`, password `nvcl` — so each request must carry an `Authorization: Basic` header.

On a **Direct** endpoint, include the header on each request (the value below is `nvcl:nvcl` Base64-encoded):

```bash theme={null}
curl -X POST http://<host>:<port> \
  -H 'Authorization: Basic bnZjbDpudmNs' \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc": "2.0", "id": "mytest", "method": "getblockchaininfo", "params": []}'
```

## Node type

Bitcoin offers two node types in the wizard's **Node type** selector:

* **Full** — keeps the complete block history and transaction index; serves the full historical RPC surface.
* **Pruned** — automatically drops old block data once it's validated, so the node runs on a much smaller disk. Compute (CPU and RAM) is the same as Full; only the storage request is trimmed. Pick it when you only need a current-state RPC node and don't serve historical block queries.

Both keep the transaction index enabled. For heavier archival or high-throughput workloads, stay on **Full** and tune the cache and index keys below.

## Config overrides

You can set `bitcoin.conf` overrides at deploy time or change them later — see [Edit node configuration](/docs/nodes/edit-configuration) for the editing flow. The common tuning keys are offered with a type, description, and guided input:

| Key                | Type    | Description                                                     |
| ------------------ | ------- | --------------------------------------------------------------- |
| `dbcache`          | number  | Database cache size in MiB                                      |
| `maxconnections`   | number  | Maximum peer connections                                        |
| `txindex`          | boolean | Maintain a full transaction index                               |
| `prune`            | number  | Prune mode: target block-storage size in MiB                    |
| `blockfilterindex` | boolean | Maintain block filter index                                     |
| `peerblockfilters` | boolean | Serve compact block filters                                     |
| `coinstatsindex`   | boolean | Maintain coinstats index                                        |
| `mempoolfullrbf`   | boolean | Accept full replace-by-fee in mempool                           |
| `assumevalid`      | string  | Block hash to assume valid (skip script verification before it) |
| `par`              | number  | Script verification threads                                     |
| `maxmempool`       | number  | Mempool size limit (MiB)                                        |

You can also set any other `bitcoin.conf` key the client accepts — keys outside the list above are still applied. Settings the platform owns — the data directory, the chain selection, ports, RPC and P2P bindings, and RPC credentials — are protected: entering one flags the row as managed by Novacula and blocks the save until you remove it.

## Metrics

The node reports block height, connected peers, sync progress, and more on its **Monitoring** and **Overview** tabs — see [Node monitoring](/docs/nodes/monitoring).

## Common patterns

* **Pruned node** — set `prune` to your target block-storage size in MiB (for example `550` for the minimum) to cap disk use. Lower the disk request in the wizard to match.
* **High-throughput RPC** — raise `dbcache` and `maxconnections` so the node keeps more of the UTXO set in memory and serves more concurrent peers.
* **Larger cache for an index rebuild** — bump `dbcache` (for example `4096` or higher) before enabling extra indexes like `coinstatsindex`; expect heavier disk use while the index builds.