Skip to content

Security: DoktorShift/NUTbits

Security

SECURITY.md

Security Policy

Security Policy

Disclaimer

NUTbits is provided as-is, without warranty of any kind. This software handles ecash tokens (real money). By using NUTbits, you acknowledge:

  • Ecash is custodial. The mint holds the funds. The mint can be compromised, shut down, or act maliciously.
  • NUTbits is a bridge, not a bank. It translates between Cashu and NWC. It does not custody funds independently; the mint does.
  • You are responsible for your own setup. Passphrase strength, seed backup, mint selection, server security - all yours.
  • No guarantee of funds safety. Software bugs, network failures, or mint issues can lead to loss of funds. Only use amounts you can afford to lose.

The authors and contributors of NUTbits accept no liability for lost funds, security breaches, or damages of any kind arising from the use of this software.

Reporting Vulnerabilities

If you discover a security vulnerability, please report it responsibly.

Include:

  • Description of the vulnerability
  • Steps to reproduce
  • Potential impact

We will acknowledge your report and work on a fix. Once resolved, we will credit you (unless you prefer anonymity).

Security Measures in NUTbits

  • AES-256-GCM encryption for all stored data (proofs, private keys)
  • scrypt key derivation from your passphrase
  • NUT-12 DLEQ verification to detect counterfeit tokens
  • NUT-13 deterministic secrets for seed-based proof recovery
  • Per-payment mutex to prevent concurrent proof corruption
  • Allocation ledger (ledger.js) - one owner for every dedicated-connection balance, with funds committed before a payment and settled after, so concurrent payments cannot overspend an allocation or reach into the shared pool
  • Conservative on unknown outcomes - if a mint does not tell us whether a melt settled, the funds stay committed and the operator is told, rather than being handed back and possibly spent twice
  • Single-instance guard - a PID lock refuses a second process against the same state backend, which would otherwise double-spend
  • NUT-05 quote resolution - an ambiguous melt is settled by asking the mint what happened, rather than guessing whether to hand the ecash back
  • Atomic NUT-13 counters - deterministic secrets are derived from a per-keyset cursor that is reserved atomically, so two operations can never produce the same blinded message
  • Durable reservations - committed funds survive a crash and come back held, so an interrupted payment is reported rather than silently forgotten
  • Atomic file writes (write to .tmp, rename) to prevent corruption on crash
  • Event deduplication to prevent replay attacks / double-payments
  • NWC secrets masked in all log output

Best Practices

  • Use a strong, unique NUTBITS_STATE_PASSPHRASE
  • Back up your NUTBITS_SEED (auto-saved to .env) in a password manager
  • Use SQLite or MySQL backend for concurrent access (LNbits)
  • Run exactly one NUTbits instance per state backend - on any backend, including MySQL
  • Only use mints you trust
  • Keep your server updated and access-controlled
  • Don't expose NUTbits to the public internet - it communicates via Nostr relays only

There aren't any published security advisories