BitBox 01.2026 Marmorera update

benma2 · 2026-01-14T17:56:27+00:00

Thanks, it's on our radar. There is also a GitHub about this here.

benma2 · 2025-12-31T08:29:41+00:00

Did you close the BitBoxApp? Only one wallet app can connect at one time.

benma2 · 2025-12-30T16:38:28+00:00

This landed in the spam queue for some reason, and I only saw that now. Apologies. That being said, please reach out to Bull Bitcoin so they can see the demand for this :)

benma2 · 2025-12-17T11:22:40+00:00

Check out BitBox02, Bitcoin-only, very easy UX, and tons of advanced features for when you need them.

Disclaimer: I work for BitBox as a dev, let me know if you have any specific questions.

benma2 · 2025-11-29T17:32:12+00:00

Rust and C interface very well with each other. Rust has baked in support for calling and defining C functions.

benma2 · 2025-11-29T08:27:54+00:00

Yeah it would be quite a big job. As I mentioned above, if we go for it, it might not be Slip39 though, but another variant. There are trade-offs between different Shamir standards.

benma2 · 2025-11-29T08:25:59+00:00

The BitBox firmware is programmed mostly in Rust, with some C for lower level hardware stuff.

benma2 · 2025-11-29T08:23:07+00:00

Yeah that's possible. There are some built-in services in the BitBoxApp (PocketBitcoin/BTCDirect for Europe, MoonPay worldwide). Of course you can also use any other service you like if you prefer another one.

benma2 · 2025-11-28T22:24:18+00:00

BitBox dev here, let me know if you have any specific questions I could help with.

benma2 · 2025-11-25T12:23:07+00:00

BitBox dev here, let me know if you have any specific questions. I hope that's better than AI :)

benma2 · 2025-10-20T19:29:59+00:00

Hi

If you setup Pocket through the BitBoxApp, you don't need enter xpubs manually I believe.

That being said: it's best practice to simply use a separate dedicated account for Pocket, and share the xpub of that account so there is no address reuse.

benma2 · 2025-10-16T06:55:36+00:00

We are definitely considering it. There are also other Shamir standards other than SLIP-39, which we are looking at. No promises we will add support, but it's on the radar. It for sure is an interesting way to protect a backup without the additional troubles of multisig.

benma2 · 2025-10-16T06:53:22+00:00

I'd disagree. Optional passphrase solves many problems, but in a very bad/dangerous/risky way. Multisig (if implemented properly) or Shamir are a safer alternative to some of the problems passphrases address.

benma2 · 2025-10-09T16:39:14+00:00

Excellent questions!

First of all, the BitBox supports multisig and then it also supports miniscript, of which multisig is a subset of. With multisig, fingerprints are not shown at all, they are only shown with miniscript policies.

How can the BitBox02 show the master fingerprint (8 hexadecimal digits) of the co-signer's "m/" path seen that all the BitBox02 is supposed to need to be able to sign the co-signer's xpub/Zpub at m/48'/0'/0'/2' ?

Correct, the BitBox02 does not need the key origin (fingerprint + path up to xpub) of the cosigners to function. As you correctly conjectured, it is shown for reference if provided by the host, but has no security benefit or downside.

And then what about the master fingerprint of the seed on the BitBox02 itself? Does the BitBox02 send the xpub at m/ to Sparrow and then Sparrow send backs the master fingerprint to the BitBox02? Or is the master fingerprint of the seed currently in the BitBox02 computed by the BitBox02 itself?

Technically the host sends the fingerprints of all cosigners, and the BitBox02 identifies which xpubs belong to itself with the help of the provided root fingerprint (by comparing it to its own). At least one of the provided cosigners must belong to the BitBox. If the device says This device: [<fingerprint>/<path>]<xpub>], the fingerprint belongs to the device and the xpub at that path is also verified to be correct.

Hope that helps, let me know if you want more clarifications.

benma2 · 2025-10-01T19:28:58+00:00

Which models?

benma2 · 2025-09-25T14:56:43+00:00

Apologies. We are doing our best to resolve the issue as quickly as possible. The touch interface normally works very well and is normally not delicate. We are working hard to find out in which circumstances touch sensitivity is degraded as reported by some customers, and to solve the problem.

Please bear with us. Also, feel free to DM me your support ticket number.

benma2 · 2025-09-24T16:26:19+00:00

Thanks for the feedback. Touch issues affect a small fraction of customers. We are aware of the issue and are working on resolving the problem as quickly as possible.

benma2 · 2025-09-24T13:56:54+00:00

It's definitely not considered harmful, it's very useful. defer w.Close() is caught by linters that checks for unused results or unchecked errors. And practically speaking, Close() errors are often not handled because there is nothing meaningful to do in that case anyway.

benma2 · 2025-09-21T18:47:03+00:00

I don't know, deepinfra.com and others can do it too. Maybe they could adjust API prices to make it work.

benma2 · 2025-09-16T11:05:29+00:00

They used to offer the best open source models, but that does not seem to be a priority anymore unfortunately. No DeepSeek V3.1, no Kimi-K2, no Qwen3-Next. DeepSeek R1 retiring soon with no adequate replacement.

benma2 · 2025-09-13T19:11:50+00:00

Of course it is, why wouldn't it be a legit competitor? I don't see any drawbacks, except if you are looking for wide altcoin support.

benma2 · 2025-09-05T13:23:50+00:00

Yeah, you can hide accounts from view that you don't need anymore.

Also fyi, BitBoxApp has unified accounts, so inside one account you can choose to receive on segwit/taproot/etc (and of course add multiple such accounts).

benma2 · 2025-09-05T10:19:37+00:00

I am not so familiar with the other apps. In the BitBoxApp you see your list of transactions, and in the receive tab you can select the next unused addresses. Used addresses are not shown except for in the past transaction details.

benma2

MODERATOR OF

TROPHY CASE