minibits-cashandClaude Opus 4.8
9d759f83ab
A mint URL is a network locator, not an identity, but it had become the de
facto foreign key for most persisted state. Changing a mint's URL therefore
had to rewrite every one of those references, and only proofs were ever
rewritten. This removes the URL from the key space where it never belonged,
and repairs the rename for what remains.
Counters (the fund-losing one)
mint_counters was PRIMARY KEY (mintUrl, keysetId), which asserts a key space
that does not exist: NUT-13 derives from (seed, keysetId, counter), with no
mint component in either path (`m/129372'/0'/{keysetIdInt}'/{counter}'` for
`00` ids, HMAC-SHA256 over the id for v2 `01`). Two rows could track ONE
derivation path independently, and a URL edit left the row unaddressable —
hydration matched on URL, found nothing, and silently restarted the counter
at 0, reusing blinded secrets the mint had already signed.
Re-keyed on keysetId alone, which is sound because keyset ids are already
globally unique wallet-wide, enforced at the door by isCollidingKeysetId per
NUT-02. Migration 32 collapses duplicates to MAX(counter), so it HEALS
wallets already split by this rather than only preventing new splits — a
too-high counter skips indices, a too-low one reuses them.
This also deletes code: persistCounter no longer walks getParent() for a URL,
so a counter detached from its Mint now persists instead of dropping its
write.
Keyset collisions and NUT-02 v2
isCollidingKeysetId applied the mod-2^31-1 keysetIdInt check to every id. That
integer only exists on the deprecated BIP-32 path; v2 ids derive by HMAC over
the full 32 bytes and never compute it. Checking it there would reject a
legitimate mint over a number nothing consumes, and re-impose v1's ~2^31
birthday bound on ids whose whole point is full-width SHA-256 resistance. The
check is now gated on derivation kind; exact-id equality still always applies.
Mint URL change
- Validation is shared with addMint via a new normalizeMintUrl, so adding and
renaming can no longer disagree. The rename previously did neither the
trailing-slash strip (NUT-00 MUST) nor the https check.
- Canonical form matches cashu-ts normalizeUrl (`href` then strip trailing
slashes). WalletStore compares our stored string to CashuMint.mintUrl to
find cached instances, so normalizing the raw input would let
`https://Mint.Example` be stored while cashu-ts held `https://mint.example`:
every cache lookup missing, two spellings looking like two mints. Pinned by
tests asserting agreement with CashuMint.mintUrl.
- The onion exemption tested `includes('.onion')`, so `http://evil.example/.onion`
bought a plain-http exemption for an ordinary host. It now tests the parsed
hostname. `startsWith('https')` also passed `https-evil://host`; now protocol
equality.
- Duplicate detection uses mintExists (normalized), not alreadyExists
(literal), which missed a trailing-slash twin and let one real mint become
two Mint nodes. Renaming to the URL already held is now a no-op, not an error.
- hostname is recomputed; it used to keep the old mint's host forever.
- transactions.mint is repointed for IN-FLIGHT rows only. That column means two
things by status: for a terminal row it is a historical record of where the
payment happened, but for an open one it is a live pointer the wallet still
calls (checkLightningMintQuote, checkLightningMeltQuote/checkOnchainMeltQuote,
findByUrl on revert/receive). Stale, it strands a paid topup at a dead URL
forever. One UPDATE, so the status test cannot straddle a transition.
- ProofsStore.updateMintUrl now writes SQLite before memory; the reverse left
the UI showing a balance the database never received.
Still URL-keyed, and documented on setMintUrl: onchain mint quotes, in-flight
requests, melt recovery and open reservations. Renaming a mint with any of
those outstanding still strands them. They need a stable mint id, which is the
next step.
Tests: 413 pass. The two new v2 collision tests fail against the previous
code and pass here, while the v1 cases pass in both. counters.test.ts mirrored
the production SQL by hand and so had asserted the old key — including a test
that two mints sharing a keyset id keep independent counters, exactly the
unsound behaviour removed here.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Minibits Wallet
Minibits is an ecash and Lightning wallet exploring how ₿-backed ecash can enable instant, cheap, and private value transfer. Ecash is issued by mints and backed by Bitcoin via the Cashu protocol and Lightning Network. Ecash is cash-like yet digital token with cheap and instant transfers and high privacy guarantees.
Disclaimer
⚠️ If you are using this app, please take the following into consideration:
- This wallet should be used for research purposes only.
- The wallet is a beta version with incomplete functionality and both known and unknown bugs.
- Do not use it with large amounts of ecash.
- The ecash stored in the wallet is issued by the mint. You trust the mint to back it with bitcoin until you transfer your holdings to another bitcoin lightning wallet.
- The Cashu protocol that the wallet implements has not yet received extensive review or testing.
Roadmap
Platform support
- Android app - Play Store, Zapstore [✨ New!] , Github
- iOS app - AppStore, Testflight and Freedomstore.io
- Light and dark mode
- i18n support
- EN, PT, ES, SK languange support
Mints
- Multiple currency units issued by mints
- Add multiple mints
- Remove mints
- Block receiving from mint
- Show mint balances grouped by currency units
- Handle mint keys rotation (not tested)
- Mint status and information screen
Receive ecash
- Scan QR code of a ecash token
- Animated QR codes support for large tokens
- Paste ecash token from the clipboard
- Receive Nostr zaps or Lightning payments to minibits.cash address
- Receive ecash from another wallet over NOSTR message sent to minibits.cash address
- Receive ecash in person while being offline, redeem later (MVP version)
- Realtime and encrypted push notifications on receive to minibits.cash lightning address
- Display or send cashu payment requests
Send ecash
- Share ecash token to send through another app
- Show ecash token as a QR code
- Show large ecash token as an animated QR code
- Send ecash to contact (minibits.cash or another NOSTR address)
- Lock ecash to the receiver wallet key (P2PK)
- Set lock expiry to allow recovery of locked ecash after timeout (P2PK)
- Scan and pay cashu payment requests
Top up wallet
- Show QR code with bitcoin Lightning invoice to pay
- Share encoded bitcoin Lightning invoice to pay
- Share lightning invoice with a contact over NOSTR message
- Top up balance with LNURL Withdraw
- Enter transaction amount in fiat currency
Pay / Cash out from wallet
- One click ZAPS - tip users of NOSTR social network
- Pay bitcoin Lightning invoice with your ecash
- Pay lightning invoices received from another contact
- Pay to LNURL Pay static links / codes
- Pay to Lightning address
- Swap ecash between mints / currencies in a single step
Transaction history
- Unified transaction history for all kinds of transactions
- Audit trail of transaction events
- Transaction search and filters [✨ New!]
- Retry after recoverable transaction errors
- Revert pending transaction in 1 click (get back tokens not claimed by receiver)
- Tags and related filtering of transactions
- Delete incomplete and failed transactions from history
Contacts
- Private contacts address book for payments
- Public contacts (followed users on NOSTR social network) for tipping and donations
- Load public contacts from custom NOSTR relay
- Wallet addresses as random public NOSTR addresses (random123@minibits.cash)
- Custom wallet names (myname@minibits.cash)
- Wallet addresses usable as Lightning addresses to receive payments from many Lightning wallets
- Private contacts with other than minibits.cash NOSTR adresses and relays
Backup and recovery
- Local append-only backup of all ecash in a database separate from wallet storage
- Export wallet backup with ecash, mints, contacts and recent transactions
- Recovery of ecash using 12 words menmonic phrase in case of lost device
- Recovery by importing wallet backup
- Move wallet address from another device using the seed phrase
- Recover wallet in case spent ecash remains in the wallet
- Retry transaction after recoverable errors
- Auto-recover funds if wallet failed to receive ecash issued by mint due to network or device failure
Interoperability
- Nostr Wallet Connect - lets you initiate payments from another app, such as Nostr client
- Deeplinks - app reacts to lightning: and cashu: URIs
- NFC - reads Cashu requests or Lightning invoices over the NFC and pays instantly [✨ New!]
- NFC HCE - Android app shares Cashu tokens, requests or invoices over the NFC [✨ New!]
Security and Privacy
- Use device biometry to login
- Connect to the mints on .onion Tor addresses using own Tor daemon [discontinued from v0.1.7]
- Connect to the mints on .onion Tor addresses using Orbot
Self-funding
- Donation for custom wallet name
DevOps
- OTA updates (opt in)
- Automated tests
- Automated release pipelines for both OTA updates and native releases
Architecture
The wallet's design has been crafted to prioritize the following primary quality properties:
- Support both Android and iOS mobile platforms
- Achieve fast UX and startup time (despite using React Native)
- Minimize the risk of data/ecash loss
- Bring ecash UX on par with the current standard of traditional finance (tradfi) mobile apps
As a result, the following architectural constraints are in place:
- Wherever available, use libraries with a fast JSI (JavaScript Interface) to native modules.
- Avoid Expo modules.
- Use fastest available storage for most wallet operations and a separate local database storage to store data that incrementally grows.
- Leverage local SQLite database as persistent storage for ecash notes.
Open architectural concepts that were still open for discussion when the wallet had been released
- Contacts management - identities, sharing contacts, send ecash with the UX of tradfi instant payment while keeping privacy towards mints - Implemented as NOSTR keypairs and NIP05 public sharable names that ecash can be sent to
- Off-device backup strategy - Implemented using @gandlafbtc concept of deterministic secrets + wallet export and import
- UX and naming conventions - ecash is not always intuitive. UX for new users heavily depends on using the right abstractions or terms to describe what is going on. This wallet wants to serve as a means to test what could work. One of the first ideas is to avoid terms such as token or proof and propose the term --coin ++ecash instead.
- Suitable Tor daemon available to replace not maintained react-native-tor. From v0.1.8-beta.33 connection through Orbot in VPN mode is possible.
Download and test
Minibits wallet is in early beta and available as of now only for Android devices. You have the following options to try it out:
- Download it from Google Play
- Join testing program on Google Play to get early releases to test (Submit your email to get an invite on Minibits.cash)
- Download .apk file from Releases page and install it on your phone
- Try on Testflight
- Download from Freedomstore.io (for EU-based users)
- Download from AppStore
Development
Minibits is a bare React Native app written in Typescript. The project structure and code itself are intentionally verbose to support readability. Critical wallet code is reasonably documented. However, there is vast space for existing code improvements, refactoring, and bug fixing. This is an early beta software and the author does not code for a living.
The code is derived from Ignite template, however with many libraries, notably Expo, stripped down to achieve fast startup times. Performance bottleneck on some Android devices is react-native-keychain. To overcome this, it has been patched not to warm-up on startup, caching for wallet operations is in place and its use to encrypt storage is opt-in.
Wallet state is managed by mobx-state-tree and persisted in fast MMKV storage. Only the basic mobx concepts are in place, whole model could be improved. All critical wallet code is in services/walletService.ts and all ecash state changes are in models/ProofsStore.ts. Wallet communication with the mints is in model/Wallet.ts and uses cashu-ts library.
Crypto operations are handled by react-native-quick-crypto, that is fast and does not require awful javascript shims. Transaction history and ecash notes are stored in sqlite, with fast react-native-quick-sqlite driver that enables to run lighter queries synchronously.
Wallet included own Tor daemon using react-native-tor library to connect to the mints over Tor network. However this seems not to be long term approach as this library is not properly maintained and future updates of React native will likely break it. Help with replacement would be appreciated.
In case of breaking state and data model changes, versioning and code is ready to run necessary migrations on wallet startup.
Running in development mode
To run Minibits wallet in dev mode, set up the React Native development environment and the Yarn package manager. Then clone this repository, navigate to the minibits_wallet directory, and run the following:
yarn install
There are post-install patches to some of the libraries that should run automatically and are necessary for a successful run. See the patches directory for more info. After the dependecies are installed, continue to create the following .env file in the root folder:
APP_ENV='DEV'
MINIBITS_SERVER_API_HOST='http://localhost/api/v2'
MINIBITS_NIP05_DOMAIN='@localhost'
MINIBITS_RELAY_URL='ws://localhost/relay'
MINIBITS_MINT_URL='http://localhost/mint'
Local NOSTR address and Lighnting brigde server are not necessary to run the wallet. Then make sure you have the Android device connected by running:
yarn adb
Finally run this and pray:
yarn start
In case of issues, repo includes commits history from the out of the box react native app up until the complete wallet. You can see build.gradle and other changes one by one and hopefully figure out what's wrong.
Building
Create debug .apk:
yarn android:dev
Automated testing
The app has the scaffolding for automated tests; they are yet to be implemented. For functional bugs or suggestions please raise an issue.
Contributing
Contributions are welcome, just start and we will figure out what's next.