Savings wallet > Wallet history (Preserve history thru key replacements)

[sahilc0]

Describe your content request

Proposing an addition to the Savings guide: a concept of “wallet/keyset history” for wallets shown by multisig coordinators (eg. Sparrow, Specter, Nunchuck, Keeper).

Link to the page https://bitcoin.design/guide/savings-wallet/

Why would you like to change the content?

Key replacements can be risky With all multisig wallets, if one of your keys gets lost or compromised, you need to go through a key replacement ceremony. When you replace a key, under the hood, you are creating a whole new wallet with a completely new set of addresses. This means that bitcoin in old addresses (secured using the old set of keys) need to be moved into your new wallet. Crucially, this also means that accidentally depositing funds to an old address (for example, if an address is whitelisted on an exchange) can put the funds at risk, since you might no longer have access to the replaced key.

Broken recordkeeping Additionally, consistent vault statements are necessary for individuals and businesses that need to account for all the transactions that have occurred over the lifetime of a vault, regardless of how many key replacements have been performed. If you lose a debit card, you don’t have to make a whole new bank account. You simply replace the debit card and update the card number with merchants, and your bank statements and transaction history persist. Bitcoin vaults should behave the same way! Recordkeeping with multisig is a challenge when every time a key replacement occurs, your transaction and address history is lost.

(From the Unchained blog: https://unchained.com/blog/introducing-wallet-history/)

Suggestions Solution

1. With a wallet/keyset history feature, a multisig coordinator software would retain your transaction history, just like a bank account, even through key replacements. You’d get a consistent, continuous experience for records of transactions and wallet statements, across all the old and new wallets that make up your parent-”wallet”.
2. Notifications that alert you to any bitcoin sent to an old address, secured by a potentially compromised key.

(From the Unchained blog: https://unchained.com/blog/introducing-wallet-history/)

[sahilc0]

Open questions / next steps

• Naming: At Unchained, the “group of wallets” is called a vault, while the group of addresses generated by a quorum of keys is called a wallet. So, in our case, “Wallet history” works fine. For other coordinator software, however, something like “Keyset history” might work better in some ways, not as much in other ways
• Advice on how to best structure this content/proposal for the guide

[GBKS]

Love it. I think we have three options for including this in the guide:

1. Sub-page to the savings wallet
2. Separate reference design (like upgradeable wallet and shared wallet)
3. A case study

For 1, the page would have to work in the context of a 2-3 multisig with a phone, hardware wallet and a key custodial by a third party.

For 3, this would basically be a write-up about the design solution Unchained has come up with, including process, visuals etc.

For 2, we would have the freedom to take bits and pieces from the Unchained solution and other solutions out there and combine them into something unique.

@sahilc0 are you more interested in describing the solution you came up with and share your process, or create more general content?

[steynviljoen67]

I might have mistaken it, but I recall @GBKS mentioning FROST in the context of wallet recovery in our previous collab call.

I don't quite get it yet, but is it relevant in this context?

[GBKS]

FROST may be a bit of a stretch for this specific issue, although it is super relevant. My understanding is that FROST is still super cutting-edge and people are wrapping their heads around it (please correct me if I'm wrong). In a classic multi-sig, you create a set of keys, and then a wallet from those keys. The keys can never be changed. If you lose a key, you have to create a new wallet and move all funds over. With FROST, you have more flexibility and can swap out keys, change from 3-of-3 to 2-of-2, etc. So if you lose a key, you can just ditch the old one and add a new one without having to make any transactions. That flexibility also comes with security considerations as attackers could also try to switch out keys to get to your funds. As I mentioned, my impression is that we need to do a lot more research around FROST before we can come up with UX guidelines.

[steynviljoen67]

Got it, thanks!

[sahilc0]

Re: FROST agreed with @GBKS I'm not super familiar with it, it's definitely not a standard right now (but now I'm really curious about it!)

@GBKS I feel like all three could work! Maybe something like: a generic description of the feature (for the guide), and then a case study for Unchained's specific implementation (for reference). What do you think?

For 1, the page would have to work in the context of a 2-3 multisig ...

Yup, this proposal would work for any multisig setup regardless of the quorum size, where the keys are stored, and who the key holders are.

[GBKS]

@sahilc0 a case study around your implementation would be amazing (was secretly hoping you'd propose that).

A good process is usually to start writing an outline in a Google Doc, get feedback and refine it over a few rounds. Then do a Figma mock-up to prep visuals and see what the actual layout looks like. You always find things to change once you see it in that format, and we have a template for it so it's not a ton of work. And then open a PR (which is pretty straightforward because everything is already figured out in the Google Doc and Figma). How does that sound?

[GBKS]

We have this covered now (since #1040) in the Multiple wallets page in the form of an "Archived wallets" feature. Going to close this issue. Feel free to re-open if desired.