Thanks, we truly appreciate your support!

SSS is an interesting approach, and even a weaker redundant seed split (aka "poor man's" SSS) can help secure the backup.

A downside (e.g., compared to multisig) is, that it only secures your backup at rest. You still need to bring the full backup together and input it into the hww, creating a single point of failure. I'm more bullish on a simple multisig implementation, as this allows to sign a PSBT sequentially, geographically distributed, never all less in one place.

Probably more of an apples/oranges comparison, though... : -)

Thanks, appreciate this! :)

I see, yes, for travelling with the backup (not just the hardware wallet) of a regular wallet, temporary encryption might be helpful.

I think the gist of this question is a general mistrust in hww. This is totally fine, and we do a lot to address these questions. There are many different aspects to this.

A blog post of mine goes into the details of how we combine a secure chip (which we don't trust) with open-source firmware. It's more important to build a robust security architecture that can handle untrusted components (for example, they never learn any secrets) and avoid singe-points of failures.

Unfortunately, verifying hardware is much more complicated than verifying software. You can't run a checksum over hardware, and there's no "reproducible build" process. All you can do as a verifyer is physical spot checks.

This is why open-source firmware is so important. You can verify the "logic" of the device, how it works, what it does, and what it does not do. It also keeps us as a manufacturer accountable.

EMC tests are part of the FCC certifaction process, and of course the BitBox underwent these checks. But these are not security checks, and no amount of them will give assurance for every BitBox, as these are just spot-checks.

Again, open-source firmware helps. The best a malicious hardware chip that is not supposed to be there can do is try a side-channel attack, for example listening in on a wire, as there's provably no code or logic that would actively use this chip. So if the chips never learn any secrets, that's the best guarantee.

For ultimate protection, to completely eliminate any trust in a specific manufacturer, there's multi-vendor multi-sig. As multiple signers from multiple vendors are involved, all of them would need to collude to pull of a targeted attack. With open-source, that can't be done in secret, so it would be a "burn all bridges and run" attack. As publicly listed companies, this is not feasible.

From a product management perspective (not the actual chip-level programming), it's important to always get user feedback and build something that is really easy to use.

Making secure hardware simple might be the real challenge.

Our blog post "How Shift Crypto protects your personal information" goes into more details, as data protection is quite a complex topic with many moving parts.

The most important duration in my view is the 30 days, after which we completely anonymize user data in our (self-hosted) online shop, actually overwriting the database fields.

I appreciate your stance and understand that it can make sense in certain cases. For this, the optional passphrase can act as an indirect encryption, as it's never stored on the device itself or the microSD card backup. Or you just skip the microSD card backup and roll your own manual backup solution based on the recovery words.

Just an option being available might create doubt in users' minds that they should use it "just to be sure". We've seen that with the optional passphrase, which is horribel UX-wise and was our support issue #1 for a long time (now fixed by forcing users through a mini-education to make sure the concept is clear).

In the end, if you build a product for everyone, you build it for noone. We decided to focus on simplicity, and that involves not encrypting the microSD backup.

The path we usually recommend is to start your own Bitcoin Treasury, get one (or more) BitBox hardware wallets to to keep your valuable stack safe, and then make a big media splash for what is basically common sense. Maybe also get a nice steelwallet, just to be sure? :)

We're not actively pushing for any specific opcodes, but are open to use new scripting techniques when this involves improving the user experience, e.g. with better backup security, degrading multisig setups, etc.

The BitBox firmware is very restrictive, however, and opcodes need to be enabled when we deem them secure. Blind signing can be a problem (where the device itself is not able to sanitized the data).

We are proud to contribute to the Bitcoin open-source infrastructure in general, and have done so many times over the years contributing to BIPs or cryptographic libraries (eg. with anti-klepto).

The LIBBTC library I actually had to look up... :) It was created by our original co-founder Jonas Schnelli 10 years ago, and I think we used it in the BitBox01. Not quite sure yet, as that was before my time.

The BitBoxApp already has password or PIN protection on mobile devices, as we can use the system libraries. Implementing password protection on desktop systems (Windows, macOS, Linux) needs more groundwork and also involves encrypting all data-at-rest. It's on our todo list, but not not actively worked on just yet.

We just launched the BitBox02 Nova with iOS support and updated hardware just two weeks ago and currently it's all hands on deck to ship the first devices. In the beginning, quality assurance is much more effort, and we're looking up to scale up production as soon as possible.

Maybe we'll need to recover a bit after that, before we start working on the next big thing... :)

We build even in bull markets! :)

We're quite happy in Switzerland, which is a beautiful place in geographical Europe, but not part of the European Union. :)

I assume that all reputable HWW (e.g., long trackk record, have a screen, fully interoperable for recovery) are secure and better choice than relying on a third party.

What we at BitBox heavily focus on is ease-of-use. I don't think that security has to be complicated, on the contrary: simplicity is part of security, as it helps avoid human errors.

The BitBox is the simples hardware wallet that "just works" with all devices (now also on iPhone/iPads) that you can give to friends and family. We build products for the next million newcomers to the space, while still making sure essential expert functions (full node support, Tor connectivity, 3rd-party wallet integrations, coin control) are available for those that need them.

A big problem with self-custody is that there always remains one thing (like the backup) that gives full and immediate access to all your coins. This piece of information must be kept secure, but should also be easy to recover.

It's hard to keep the backup secure, and as long as users at home have immediate access to all their funds, that can make them targets for the $5-dollar-wrench-attack.

A few options that try to fix this:

Not having instant access to your full stash should be normalized, so thieves can no longer assume that a "friendly visit" at home will pay off.

Appreciate it! :)

I know this is still an unpopular opinion, but airgap in itself does not really add to security. On the contrary: more secure protection protocols (like "anti-klepto") are so complicated on airgap wallets, that they are simply ignored and downplayed. In this sense, "airgap" is mostly a marketing term, without much substanse. We wrote an extensive blog post (fact-based, with sources) on this for further reading: https://blog.bitbox.swiss/en/does-airgap-make-bitcoin-hardware-wallets-more-secure/

For easy integration into 3rd-party wallets, however, "airgap" communication like QR codes, PSBTs via microSD cards or NFC is great. We currently don't have any plans for this with the current BitBox02, however. Although the microSD card would be a natural fit to "load" a PSBT, we fear that users would mix up their backup mSD card and put it into an online device.

I'm curious to hear more about the motivation behind the question: security, wallet integration, or something else?

Thanks, glad to hear! While the BitBox02 has come out in 2019, it is still going strong and the hardware is basically unchanged. The new BitBox02 Nova is an evolution, especially for iPhone users and we'll keep building out both version in parallel.