Add Bitcoin Safe to wallets

[andreasgriffin]

Adds Bitcoin Safe as a desktop wallet to Bitcoin.org Wallets section.

Supported by opensats

Reproducibility: https://walletscrutiny.com/desktop/bitcoin.safe/

@design-rrr

[crwatkins]

Thanks for your submission!

Have you carefully reviewed the criteria for listing and verified that Bitcoin Safe meets those criteria?

[andreasgriffin]

@crwatkins Yes I reviewed all criteria and Bitcoin Safe meets all applicable ones imho.

• For maximal security Bitcoin Safe requires hardware signers (all major ones supported) on mainnet

[crwatkins]

Thanks much for the careful review.

[crwatkins]

• In the description, could you remove the hanging dash in "single-"? Perhaps replace with "single signature".
• Is it correct that by default centralized servers are used for validationin the current version being reviewed? If so, the validation score should be checkfailvalidationcentralized
• Since the privacydisclosure is checkfailprivacydisclosurecentralized the privacy should be checkpassprivacybasic

Let me know if you agree. I've done dozens of these and I still have to go back and read all the descriptions.

[andreasgriffin]

• In the description, could you remove the hanging dash in "single-"? Perhaps replace with "single signature".

Sure. I'll do that.

* Is it correct that by default centralized servers are used for validationin the current version being reviewed?  If so, the validation score should be `checkfailvalidationcentralized`

I was orienting myself at

Bitcoin.org/_wallets/sparrow.md

Line 21 in 7f62c1d

validation: "checkpassvalidationservers"

since the choice of electrum severs has a default, but can be freely chosen by the user (identical to sparrow).

* Since the `privacydisclosure` is `checkfailprivacydisclosurecentralized` the `privacy` should be `checkpassprivacybasic`

Again I was orienting myself at

Bitcoin.org/_wallets/sparrow.md

Line 24 in 7f62c1d

privacy: "checkgoodprivacyimproved"

. While sparrow, does allow connecting a full node, this is not the default.

Let me know what you think, and what values I should change.

[crwatkins]

It was quite a while ago, but I think the reason that Sparrow chose that validation score was that I believe Sparrow selects the server randomly by default from a list like described in checkpassvalidationservers. I seem to remember the privacy score was similarly chosen for Sparrow because the startup wizard took the user through multiple screens of explanations on the different options for servers and requested that the user choose one. Although the user could click away from the choice and be assigned a random server, that choice was discouraged by the wizard. I believe one could argue that Sparrow should have been assigned checkfailprivacydisclosurespv and that could be a matter for a PR.

I'm still leaning toward my recommendation above based on my interpretations, but would be interested in any discussion on the matter as it is often tedious to try to assign these subtly different scores that were created a decade ago to modern wallets, particularly when they sometimes imply that one approach is unconditionally superior to another.

[crwatkins]

I have reviewed Bitcoin Safe wallet based on the current wallet requirements criteria and my evaluation is below. The summary is that the wallet passes on security and overall design and I'm glad to recommend Bitcoin Safe wallet for listing.

A unique characteristic of this wallet is that it does not store keying material nor is it ever exposed to keys. An external hardware wallet is required for signing. Therefore some of the standard requirements below are not applicable. Trezor model T, Coldcard Q, and Foundation Passport were used during the review, but were not evaluated. Also, none of the nostr based features of the wallet were reviewed.

A strong feature of the wallet is the exceptionally good user experience for onboarding multivendor, multisignature hardware wallets. It's clear a lot of work has been put into the onboarding, however the wallet is fairly new and the user experience for daily operations (e.g. send, receive, monitoring) is not as polished. Multiple minor issues were reported and it is expected that they will be addressed in future releases.

This project is fairly new and has had limited user feedback from the normal sources with a few of them listed below. It is usually expected to have much more user feedback (both good and bad count) to demonstrate a certain ambiguous level of usage before listing. However, since this project does not manage private keys, many of the most common risks are simply not present. Therefore, I'm willing waive the usual high bar of user engagement early and recommend Bitcoin Safe for listing.

I concur with the scoring in bc72708.

---

Bitcoin Safe Wallet

Version v1.5.0

Review Version 2025110901

The wallet list is based on the personal evaluation of the maintainer(s) and
regular contributors of this site, according to the criteria detailed below.

These requirements are meant to be updated and strengthened over time.
Innovative wallets are exciting and encouraged, so if your wallet has a good
reason for not following some of the rules below, please submit it anyway and
we'll consider updating the rules.

Basic requirements:

• Sufficient users and/or developers feedback can be found without concerning
  issues, or independent security audit(s) is available

NOTE Only very minor user engagement was found. Searching for engagement is very difficult because of the name of the project.

• https://bitcointalk.org/index.php?topic=5556034.0
• https://www.youtube.com/watch?v=H4ItgHC20lQ

• No indication that users have been harmed considerably by any issue in
  relation to the wallet

PASS No indication

• No indication that security issues have been concealed, ignored, or not
  addressed correctly in order to prevent new or similar issues from happening
  in the future

PASS No indication found

• No indication that the wallet uses unstable or unsecure libraries

PASS No indication. Uses the bdk libraries.

• No indication that changes to the code are not properly tested

PASS No indication. Test are here https://github.com/andreasgriffin/bitcoin-safe/tree/main/tests

• Wallet was publicly announced and released since at least 3 months

PASS 1.0.0 was released on 15 January 2025

• No concerning bug is found when testing the wallet

PASS No concerning bug was found. The developer was very responsive to all reported issues.

• Provides a bug reporting method on the website and/or in the app

PASS App has About->Feedback/Contact section

• Website supports HTTPS and 301 redirects HTTP requests

PASS http://bitcoin-safe.org redirects to HTTPS

• SSL certificate passes Qualys SSL Labs SSL
  test

PASS https://bitcoin-safe.org rating: A+

• Website serving or linking to executable code or requiring authentication uses HSTS
  • Existing listings: With a max-age of at least 180 days
  • New listings: With a max-age of at least 1 year, and preload and includeSubDomains directives to qualify for browser preload list inclusion
    e.g. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

PASS https://bitcoin-safe.org

• The identity of CEOs and/or developers is public

PASS Developer is Andreas Griffin, OpenSats grant awardee.

• Avoid address reuse by displaying a new receiving address for each transaction
  in the wallet UI

PASS A new address is displayed for each transaction

• Avoid address reuse by using a new change address for each transaction

PASS

• Uses deterministic ECDSA nonces (RFC 6979)

N/A Bitcoin Safe does not sign transactions

• User has access to private keys for all major components of the wallet

N/A Bitcoin Safe does not store private keys

• If private keys or encryption keys are stored online:
  • Refuses weak passwords (short passwords and/or common passwords) used to
    secure access to any funds, or provides an aggressive account lock-out
    feature in response to failed login attempts along with a strict account
    recovery process.
• If user has exclusive access over its private keys:
  • Allows backup of the wallet
  • Restoring wallet from backup is working
  • Source code is public and kept up to date under version control system
• If user has no access to some of the private keys in a multi-signature wallet:
  • Provides 2FA authentication feature
  • Reminds the user to enable 2FA by email or in the main UI of the wallet
  • User session is not persistent, or requires authentication for spending
  • Gives control to the user over moving their funds out of the multi-signature
    wallet
• For hardware wallets:

N/A

• Uses the push model (computer malware cannot sign a transaction without user
  input)
• Protects the seed against unsigned firmware upgrades
• Has capability to prevent firmware downgrades
• Supports importing custom seeds
• Provides source code created for all open components and provides detailed specification for blackbox testing of
  any closed-source secure elements

Optional criteria (some could become requirements):

• Does not show "received from" Bitcoin addresses in the UI

PASS Does not show "received from"

• Website serving executable code or requiring authentication is included in the
  HSTS preload list

FAIL https://bitcoin-safe.org is not included

• If user has exclusive access over its private keys:

N/A Bitcoin Safe does not store private keys

• Supports HD wallets (BIP32)

PASS

• Provides users with step to print or write their wallet seed on setup

PASS Prints extremely complete worksheets

• Uses a strong KDF and key stretching for wallet storage and backups

PASS Uses PBKDF2

• On desktop platform:
  • Encrypt the wallet by default

PASS