Great question.

We address this in a few ways.

First, Nunchuk was built on open standards. BSMS is a BIP. It is actually a thin wrapper over Output Descriptors, invented by sipa and supported by many popular wallets such as Sparrow and Specter. We also support other wallet configuration formats, such as Coldcard or UR2. This means that you can easily recover wallets created in Nunchuk elsewhere. Here is an example recovery guide.

Secondly, our assisted wallets are all multisig wallets whereas Nunchuk the platform only holds one key, and the other keys are held by the user. That means the user always remains in full control of their funds.

Thirdly, regarding the inheritance planning aspect, we recommend users to use a rolling short timelock. This mitigates the risks of Nunchuk going out of business and also anything unfortunate that might happen to you.

Update on BSMS: Sparrow Wallet now supports it as well !

S2F was a scam? :)

Seriously though, I think one thing that other Bitcoiners might disagree with me is regarding priorities.

Some Bitcoiners place a high premium on instant payments. Some Bitcoiners place a high premium on privacy.

But I believe without strong technologies to HODL a.k.a. making self-custody safe and accessible to millions of people, none of the other stuff we build matters. Having instant payments or "perfect" privacy is moot if we can't secure bitcoin over multiple generations.

Because Bitcoin is to me primarily a saving technology. It needs to excel at that, first and foremost.

Thank you! The Freedom Convoy incident was definitely one of the highlights of the year for us. We are able to laugh about it now, but at the time it was pretty stressful haha.

Integration with LN is definitely a cool idea, and something we've been asked often.

I wouldn't rule that out, but want to stay focused on multisig / solving self-custody challenges first. Once we are satisfied with the state of multisig, we can definitely explore other areas.

The nice thing about waiting is that we'll also get to see LN mature. By the time we choose to integrate, the tech stack and protocol would be a lot more tested and defined. We can build on LDK for example instead of rolling our own ad-hoc solutions.

Multisig ftw!

I don't think it is a matter of costs, but perhaps user education and awareness. Though things have vastly improved, most users still do not self-custody and choose to leave coins on centralized exchanges. That needs to change first before multisig can be more mainstream. So I'd rephrase your question as: how can we make self-custody of bitcoin more mainstream?

I think it will come, but will take time. This is a zero-to-one technology after all. Gold didn't emerge as the dominant form of money over night. It took thousands of years. I don't think Bitcoin adoption will take that long, but we are talking about perhaps decades. (Or who knows? maybe some major fiat currency will collapse tomorrow).

Demand will also naturally rise as the market cap of Bitcoin increases. You'd think twice about leaving a million dollars on a CEX or a singlesig wallet, vs. $50k.

Great question !

I think becoming a parent is definitely challenging for founders. Raising a baby is a full-time job. Full stop.

On the other hand, it has given me a clear focus and an additional boost of motivation. My time is currently roughly split 50-50 between the baby and building Nunchuk. I've removed all the other distractions out of my life, pretty much out of necessity.

Fortunately my wife and my family has also been super supportive. It also helps that this job allows me to work remotely, so I do have some flexibility. Thank you Bitcoin!

All in all, it's great so far!

Certainly.

Existing Bitcoin inheritance solutions roughly fall into 2 major categories:

The first one is relatively simple to understand (but not simple to implement), and probably the most common. Basically you would share all your keys and wallet data directly with the beneficiary, as well as the instructions to recreate said keys and wallet from scratch.

The problem with that is that this potentially creates a security vulnerability. You might be confident in your ability to safekeep sensitive key material, but it's hard to say the same for your family. The more copies of the keys you create, the easier you make it for a potential attacker. Furthermore, if the wallet is a multisig or uses a custom setup, the instructions can be quite difficult to follow, especially for someone non-technical. (You can perhaps "mitigate" this complexity by keeping your bitcoin in a singlesig wallet, but this comes at the cost of being more vulnerable to SPOFs).

Pre-signed transactions, on the other hand, require you to lock UTXOs. This technique interferes with your daily wallet usage. Every time you have a new transaction, you'd need to update the pre-signed transactions. You also need to pick transaction fees in advance, which may be problematic as we transition into the fees era, and the fee rate might become more volatile - the pre-signed transactions might get kicked out of the mempool. Last but not least, pre-signed transactions require you to pick the destination address/wallet in advance. This to me is its weakest point. The more time passes, the more uncertain we will be about what happens to the destination wallet. Will the beneficiary still have control over that wallet? Has any of its keys been compromised? etc. A lot can happen in 10-20 years.

Our Honey Badger solution solves this by having a dedicated inheritance key. The beneficiary does not need to know everything about the original wallet/keys in order to claim the inheritance. And we have tried to simplify the process as much as possible. The inheritance key is also time-locked, so you don't have the same vulnerability as the typical key duplication technique.

And of cos with that we are also able to sidestep all the problems with pre-signed transactions, since the inheritance claim happens on-demand on a future date, not now.

Hope this answers your question.

Thank you!

Of course and we'd love that. Our built-in encrypted chat might prove useful for the construction of the P2EP transaction. The sender and recipient can exchange UTXOs data securely over the encrypted comm.

Feel free to submit a PR into our core repo: https://github.com/nunchuk-io/libnunchuk/issues

I think it's awesome that we have multiple multisig wallets / multisig service providers in Bitcoin. In the past few years, great progress has been made in terms of inter-operability (PSBTs, descriptors, etc.), so that the users don't have to be "locked in" to any particular wallet / vendor. This diversity of choices is great for the end users, and directly contribute to strengthening the entire Bitcoin ecosystem.

If anything, I think multisig is significantly underinvested, especially when compared to something like the Lightning Network. I would love to see more multisig projects / more experimentation in the future.

The decryption process happens entirely locally on the claimant's device. At no point in time Nunchuk possesses two keys.

Absolutely!

Our app currently supports the singlesig version of Taproot. However, Taproot multisig is where the biggest gain will be. It is definitely on our roadmap.

Answered on Twitter! Relevant thread here for those interested:

Sure !

Honey Badger is an 2-of-4 "assisted" multisig wallet. The platform holds one key (the "platform key"), while the owner hold three keys, including a designated inheritance key. The designated inheritance key is exclusively reserved for inheritance planning, and not daily spending.

This design was inspired by the separation-of-concerns principle. The inheritance key allows us to separate daily security concerns from inheritance concerns.

The inheritance key is timelocked, meaning a beneficiary can only access it to claim the inheritance on a future date set by the owner. Currently the timelock is enforced off-chain by Nunchuk the platform. In the future we will also explore the on-chain timelock option.

Honey Badger also has some other powerful features, such as policy control (for the platform key) and scheduled transactions.