How can we improve the multi-key section of the guide?

[GBKS]

We have a short note about improving multi-key content on our roadmap brainstorm board, so I'd like to discuss how we should do this. What do you think? What's missing?

I'd like to suggest that we combine this with another idea around beefing up the detail and fidelity of case studies. There are a lot of screens in the MyMattress design that I am currently merging into the Wallet UI Kit, which could easily be adopted for a beefed-up Savings account case study. Some screens are also relevant to the Upgradeable wallet case study, although I would focus on updating one case study at a time.

Specifically, I'd lay out these sequences in much more detail:

• Onboarding
• Send
• Recovery / key rotation

To avoid too much overlap, I would not duplicate onboarding and transaction content from the existing sections, but keep those parts short and refer back to the dedicated sections. That way, the case study can focus on the unique aspects of multi-key experiences.

My suggestion is really about the savings account case study. Are there other multi-key related areas that we should also improve?

[psacramento-gh]

When it comes to inspiration on how to explain things clearly, I would like to recommend watching this excellent webinar by Casa: https://youtu.be/p36yw9fOYLs

Secondly, I would start trying to improve the copy of the existing content.

All of the previous schemes have relied on a single private key to control the wallet. This presents an all-or-nothing risk for loss of funds from both theft and negligence.

I would add that with multisig the funds are also secured in case of sudden death, natural disasters and platform breaches.

• If a single person dies, the funds can still me moved.
• If a single location where a signing device is destroyed, the funds can still me transferred.
• If a certain platform/operating system is compromised leaking a key, the other devices may still be used safely.

To counter this a wallet can have several private keys attached of which all or a subset need to sign any transactions.

I believe it is important to state that the multiple keys are necessary only for signing outgoing transactions, but not for receiving.

[sbddesign]

I believe it is important to state that the multiple keys are necessary only for signing outgoing transactions, but not for receiving.

Agreed. Multi-sig can sound very complicated to people, but once you know that you can still receive funds while only holding one of the keys, it begins to sound a lot more feasible to someone.

[moneyball]

For on-chain bitcoin, one doesn't need to have any keys online to receive funds. To spend, you need k of n keys in a k of n setup. So I'm not sure what is meant by "while only holding one of the keys."

To receive bitcoin on LN, currently single sig is only supported on LN. In the future multi-sig can be supported, and when it is, users will need k of n keys to be online in order to receive bitcoin.

[psacramento-gh]

I took the liberty of creating this PR: #426

[sbddesign]

@moneyball Yes, good point. I was wrong on that. In my mind, I was envisioning using a multi-sig app on a mobile phone to generate a fresh address in a 2-of-3 setup, where the phone only has one key. But now that you mention it, I believe the phone would be able to generate fresh addresses because it would have the xpubs for each key in the 2-of-3 setup, and would have nothing to do with actually having a private key online. If my understanding is correct.

(And then it would always be able to receive funds from an old address regardless, though that wouldn't be recommended practice).

[moneyball]

There are different use cases and many different combinations for private key management. It isn't practical to describe all variations, but my hope is that guide either explicitly walks through a few concrete best practices examples (ie case studies) or provides enough detail in its guidance that someone using the guide could easily conclude with a design that is/could be a case study. Two in particular that stand out to me as possible best practices:

1. Muun wallet's 2of2 and all of the details involved
2. The 2of3 I described here which nicely encompasses savings and spending in the same wallet https://bitcoindesign.slack.com/archives/C01TTD8Q7ST/p1623851331042000?thread_ts=1623821067.021300&cid=C01TTD8Q7ST

[GBKS]

Both Muun and the 2-of-3 scenario you describe involve a third party. Are you thinking this would always be some companies servers? It'd be great if there were also self-hosted alternatives, like an Umbrel app that specialized in just this type of signing mechanism (with any limits I may have set up). Are you aware of any pure signing apps that try to tackle this?

The Savings account case study is very close to your 2-of-3 scenario, we should use that foundation and iterate on it.

The Muun example might be well-served for our primary case study that we base onboarding and payments on (and would include Lightning).

[moneyball]

I definitely think the guide should also have an example best practices that does not require a 3rd party.

That said, I think it will be quite common for mainstream usage and a good UX to utilize a 3rd party. In addition to Muun and the 2of3 example, Casa does this too (they hold 1 of 5 keys). And Photon too is designed in such a way that a 3rd party would run the Photon server.

Yes, a self-sovereign individual could run the Photon server themselves or run Casa's 5th key service or the 3rd key in the 2of3 described, but then it isn't assisted self custody, it is simply an individual managing all N keys in a K of N multi-sig. Nothing wrong with that but you lose a lot of advantages by leveraging a 3rd party. (we should point out privacy tradeoffs though)

[GBKS]

Daniel and I started messing around in Figma with an update to the savings case study. Here is a video with first design mock-ups, would be fantastic to get your feedback on it before detailing it further. https://youtu.be/qkGZMW_s6EU

[Bosch-0]

I agree with Steve that primarily we should focus on one or two concrete examples (Muun is the example I would recommend also) rather than laying them all out. We should also attempt to improve on models like this. An example for Muun would be to make their recovery kit more interoperable as currently restoring it in another wallet is difficult.

I like the approach of having a separate section that does a deeper dive into a multisig vault type product and keeping the primary body of the guide focused on one scheme in the context of a mobile first, non-custodial, Bitcoin Lightning product. If that involves multi-key methods, add it, if not, discuss it in later sections.

[psacramento-gh]

I agree with you both (@moneyball and @Bosch-0 ) that we should focus on concrete examples. They are going to make it easier to understand the possible applications of different schemes.

But am I the only one that thinks that there's still some room for expanding on why multi-key matters?

If you guys find that it is good like this, we can move on to the the examples.

But what I am proposing is just adding some bullet points explaining further advantages of using a multi-key in the introduction part of this page.

It could be something like the following:

Multi-key provides an extra layer of security. This is achieved by improving the protection of the wallet against the dangers that arise when:

• a single person is in full control of the funds
• a device has being stolen/destroyed in a particular location
• a certain technical piece of software or hardware has being somehow compromised

As I understand, our audience consists of not only developers seeking to learn about design best practices, but primarily of designers learning about bitcoin tech.

I believe our target audience can profit from this kind of further explanation.

[GBKS]

I think your first bullet is already covered at the top of the page, but spelling out other benefits could be good. The page already has a lot of bullet lists, do your points maybe fit in an existing one?

[moneyball]

Sure I didn't mean to imply I don't think we can't improve describing advantages of multi-key.

Fundamentally the most important reason is that with multi-sig there is never a single computer that has the key material to spend funds. Instead, multiple separate computers each partially sign a transaction and those are then combined on a computer, but at that point the transaction can only spend the amount committed to and to the destination(s) committed to.

There are also other benefits of course such as having a single wallet be used for both savings and spending, and applying different UX/security tradeoffs to each of those use cases, as in my 2of3 example.

[psacramento-gh]

Awesome! I have started structuring what you guys said in this document: https://docs.google.com/document/d/1LL8NSFvpDWYCvyu_VVS9nvTdYUP-4P7x9Mf1SmrIhnc/edit?usp=sharing

I suggest we use it as a sketch board for the text that will be used later in the page on the Guide.

Afterwards we can start making the graphics.

The last step would be to bring it all up together into the page of the guide.

[Rspigler]

I think what's also really important to work on, is the UI/UX for the new standards around multi-signature; BIP 87 and BIP 129.

There are also BIPs-in-process for descriptors (achow101/bips#3). The standardization of secure set-up, derivation paths, and descriptors cover the entire process of set-up, configuration, and recovery.

[GBKS]

Great idea. We should also add these to the wallet interoperability page, possibly with a note that they are emerging standards (and not accepted & widely adopted).

[johnsBeharry]

Partially Signed Bitcoin Transactions are also something to factor in for hardware-based multisig setups since they are constructed and signed.

We can update the transaction page to mention this. I like to explain transactions as files and the bitcoin application as an editor for that file, you can then send the file to someone out of band for them to also import and modify. Authorisations are needed for the transaction if you construct it by yourself or with someone else. Also, some of those bitcoin applications have the ability to broadcast some may not.

I've made such kind of direction in PR #84 (Preview)