minibits-cashandClaude Opus 4.8
c56729aa38
Two things, coupled because the first could not be tested without the second. Detect the proofs/mint desync, and change nothing `proofs.mintUrl` is a denormalized copy of a mint's LOCATOR, joined to `mint.mintUrl` by string equality across two persistence engines — proofs in SQLite, mint.mintUrl in the MMKV snapshot. A crash between those writes during a mint-url edit desyncs them, and the balance view then counts the proofs in the unit total while attributing them to no mint, which also makes them unspendable (send and melt select by mint). Money visible in the header, owned by nothing. reportOrphanedProofs() reports that and does nothing else. Deliberate: the sats are the user's, and hiding them, refusing to start, or forcing a recovery are all worse outcomes than a total that reads slightly high. The state self-heals once a mint is (re-)added at that url. It runs at STARTUP, not from `balances`, for two reasons. `balances` is a MobX computed that re-runs on every proof and mint change; and mint removal legitimately produces this exact state for a moment — MintsScreen destroys the mint in one action and moves its proofs to SPENT in the next, so reactions observe the gap. Detecting there would have fired on every normal removal, which is how an alert teaches you to ignore it. At startup the tree is settled, so anything found is a genuine persisted desync. Untangle the model layer MST stores could not be instantiated in a test at all, which is why this repo has no store tests — only mirrored SQL and pure functions. The cause was not jest: the model layer transitively imported most of the app. Five real defects: - logService imported `../models` and destructured rootStoreInstance at MODULE SCOPE, while models/index eagerly instantiates the root store. A leaf logging service pulling the root store inverted the graph, and whether it worked came down to which module loaded first — the app has an entry order that survives it, a test importing a model directly reads RootStoreModel as undefined and throws during import. Now a deferred require, resolved on use. - Mint imported the `../theme` BARREL, which re-exports useThemeColor -> ../services — the whole service layer, to read two colour constants. - Five models imported the `../services` BARREL for log/Database, dragging in walletService -> syncQueueService -> notificationService (notifee). - currency.ts imported the `../../components` BARREL for currency icons: a service module depending on the entire UI. (ChfIcon was already imported directly — it was inconsistent as well as wrong.) - generateId lived in utils.ts beside a react-native-flash-message toast, so generating an id pulled in the UI stack. Split into its own module; utils.ts re-exports it, so existing callers are unaffected. None of these change behaviour: same modules, narrower paths. Test harness jest already used the react-native preset; the gap was native and source-shipped packages that the model layer reaches at import time. Mocks for MMKV (Map-backed, behaves), op-sqlite, Sentry and nostr-tools, plus resolver mappings for @scure/bip39 wordlists and nostr-tools' subpaths — its vendored @noble copies ship source and importing them would cross versions on crypto code, so the surface is mocked instead. op-sqlite and nostr-tools THROW if actually called: a test that silently derives a bogus key and asserts on it is worse than one that stops and explains. Real DB semantics stay where they were, on node:sqlite with the production SQL. Mocking Sentry rather than logService means suites can let the real logger load. The full RootStore still cannot instantiate (AuthStore/NwcStore/ WalletProfileStore pull the service layer), so orphanedProofs.test.ts uses a minimal root — enough for the money models, and enough for what comes next. Also removed: Mint.setRandomColor and theme's getRandomIconColor. The helper's only caller was that action, and the action had no callers at all. Tests: 433 pass, including 12 new ones against the real MST models — the first store tests in the repo. They pin the promise above: an orphaned proof still counts in the unit total, reporting mutates nothing, and it heals when the mint returns. 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.