Pavao
← Bitcoin Core

In development · Coming soon

Ordinary hardware.
A dedicated environment.

Tux, the Linux penguin, with the Bitcoin logo on its belly

I am preparing stripped-down Debian ISO images for three Bitcoin Core roles: offline signing, wallet creation and backup, and running an online node.

Keep the software each role needs. Leave browsing, email and unrelated everyday applications on another computer. For meaningful funds, I recommend dedicated hardware with a fresh Linux installation. A clean antivirus scan does not make a daily computer a trusted environment for wallet secrets.

01 · Offline · Live RAM only

Bitcoin Core offline signer

A minimal Debian environment running Bitcoin Core exclusively as a live session in RAM. Boot from the image, create or load a wallet, review a PSBT and sign it offline. This signer profile is not installed on the internal disk. The online node validates the chain and broadcasts the signed transaction.

The signer is intended to stay disconnected. No browser, email client or general office suite. The offline signing role does not need a synchronized blockchain.

Export the wallet backups and signed transaction files you need to removable media before shutdown or restart. Unsaved session data is lost when the session ends.

Learn the offline-signer workflow →

02 · Offline · Live RAM or installed

Bitcoin Core Vault

An offline environment for creating, encrypting, backing up and restoring Bitcoin Core wallets. Use it live in RAM, or install its operating system with Calamares. Both modes keep the Vault account’s home and private working data in RAM. An installation preserves Debian and the applications on the internal disk; the private session starts fresh.

  • Bitcoin Core for wallet operations and PSBT signing.
  • KeePassXC for generating passwords and passphrases and managing a password database.
  • GnuPG for symmetric encryption of the whole backup: one GPG layer by default, with additional independently protected layers when needed.
  • GNU TAR for packaging files and folders before encryption. TAR is packaging, not encryption; Vault is intended to handle it for you.
  • Thunar for files and removable backup media.
  • Mousepad for local notes and recovery instructions.
  • Brasero for optical backup media.
  • CUPS and printer tools for locally printed recovery material.

GPG backups, with independent layers when needed

The upcoming redesign uses standard GPG encryption around a consistent Core wallet snapshot or TAR payload. It targets authenticated AES-256 OCB encryption. Each additional layer uses its own randomly generated passphrase; the Core wallet passphrase remains a separate secret. Encrypting the payload hides the wallet metadata and filenames inside it, while the outer filename, size and storage timestamps remain visible.

Multiple layers require every layer’s secret. Keep redundant recovery records and separate locations deliberately; storing all passphrases together defeats that separation. This protects backup access, not Bitcoin signing authority, and is not multisig. Only the final outermost file belongs in distributed backup storage.

Recovery is designed to work without Vault: decrypt each layer with compatible standard GnuPG, extract TAR when present, then restore the wallet in Core. The release will document the tested GnuPG version and OCB profile. Prove that full recovery independently before relying on the backup.

Practise GPG backup and recovery now →

A stateless private session

Wallets, password databases, settings and temporary working files stay in the RAM workspace. Swap, hibernation and persistent crash dumps are disabled in the current configuration, and session logs are volatile. Core’s launcher restricts writes to checked RAM locations.

The redesigned Wallet Backup workflow will export the final encrypted .gpg file to USB, optical or other removable media, with verification before completion. Export any password database, recovery notes or signed PSBT you want to keep too. Finish Private Session checks the wallets against verified exports before discarding the workspace. Shutdown, restart or power loss loses anything left only in RAM.

What “stateless” covers

It describes the private working session, not every possible write a user can make. Exported backups remain on their destination media. Tools such as the file manager and text editor can also write elsewhere if you deliberately choose another destination; use Private Workspace for temporary sensitive files. Ending the session does not erase old disk contents or certify physical RAM sanitization.

This is the planned GPG-based toolset for the upcoming Vault release. The release manifest and testing notes will document the exact contents and verified behavior of each published image.

Learn the backup and recovery workflow →

03 · Online

Dedicated Bitcoin Core node

A separate minimal Debian image for running an online Bitcoin Core node: validating the chain, maintaining the watch-only wallet, constructing PSBTs and broadcasting signed transactions.

Planned without a browser, email client or unrelated desktop applications. Networking serves the node and its deliberate maintenance. In the offline-signing architecture, the private signing keys stay on the offline machine.

The node retains its blockchain and watch-only state between sessions. Its storage role is different from the volatile private workspace on the offline signer and Vault.

Understand the two-machine architecture →

Sources and independent verification

Trace the software. Inspect the preparation.

The images are prepared Debian environments built around existing open-source software. Debian packages come from the official Debian archive; Bitcoin Core uses the unmodified upstream release. The current Vault build also contains project configuration, helper programs and locally built or patched packages, including the Vault interface, Thunar and the installer. Those additions belong in the review too.

Each release will link to its exact package manifest, upstream versions, build configuration, local source code and patches, alongside the ISO and verification instructions. The aim is to let you check what was included and reproduce the preparation yourself.

  1. Authenticate the image. Compare its SHA-256 checksum with the signed release checksums and verify the signing key through an independent trusted channel. This identifies the published image; it does not by itself prove the contents are safe. Debian explains image verification.
  2. Verify the upstream software. Check Debian package provenance against signed archive metadata using APT’s trust chain. Compare Core against its upstream hashes, signatures and independent build attestations. For direct KeePassXC downloads, use its signature-verification instructions; the Debian-packaged version is verified through Debian.
  3. Review every project addition. Read the package lists, boot settings, launchers, helper programs and local patches. Compare files inside the image with the documented inputs. A local patch must be disclosed and checked, even when its starting point was an official source.
  4. Build and compare independently. Rebuild from the recorded inputs in a separate environment and compare the output and contents. A claim of byte-for-byte reproducibility requires a matching independent build; it is not implied by publishing source code or a checksum. Reproducibility of these complete ISOs has not yet been established here.
  5. Check the session behavior. In a disposable test session, inspect the RAM mounts, confirm that swap is inactive, export a test wallet, shut down and prove recovery from the external backup. Source and image checks complement these runtime checks.

Release status · October 16, 2026

The images are coming. The learning path is already open.

The new ISO downloads are not available on this page yet. When released, each image will have its own download link, version information, checksums and verification instructions. The same links will be placed in the curriculum where you prepare the operating system, set up the signer or node, and practice wallet backup and recovery.

You can follow the existing Debian and Bitcoin Core lessons now. The prepared images are intended to reduce setup work; understanding the environment and proving recovery remain part of the process.

These are independent BTC Pavao projects built around Debian and Bitcoin Core, not official releases of either project. The release documentation will distinguish the live-session and installation workflows and state what persists after shutdown.

Start the Bitcoin Core curriculum →

Apply this to your situation

What would a simpler custody setup look like for you?

We can work through your threat model, Bitcoin Core workflow, backup and recovery plan, or the authority your spending policy needs to express.

Book a 15-minute introduction to outline the question and decide whether a longer session would help. If we arrange one, that session is Value for Value: afterwards, you decide what it was worth. No fixed fee or obligation.

Book a 15-minute introduction

Please keep private keys, passphrases, and wallet files out of the booking form.

An open book encircled by small brass markers on a sunlit Mediterranean stone table, symbolizing open knowledge and voluntary exchange.

Value for value

Did this help you?

Everything I publish here is openly available. If this work has been valuable to you, you can return value in whatever amount feels appropriate. Your support helps me keep Bitcoin education, articles, guides and other resources open and freely available to everyone.

No fixed price. No paywall. No obligation.

Return value