Savings wallet reference design discussion

[Bosch-0]

Hey guys,

Looking to work on improving the Savings wallet reference design and wanted to start a discussion around what the scope of it should be. By scope I mean what features, platform, limitations etc. will be included within the reference design. The goal is to have a wallet with carefully balanced UX and security. Below is what I have in mind so far:

• A savings wallet for a standard, non-technical, bitcoin user.
• Mobile-first (caters to the largest amount of users)
• Bitcoin-only
• Collaborative custody, meaning a third-party service holds 1 of 3 keys and is is used as a co-signer for some payments / failsafe similar to Unchained, Casa and Blocks upcoming wallet
• 2 of 3 multisig (3 of 5 + is more suited for shared custody wallets)
• One app key, one external key (hardware device or card), one key with third-party.
  • External key is REQUIRED to setup this wallet
  • External key uses NFC to sign / share info.
    • As this external signer most likely won't have a key, email transaction confirmation could be used (recommend user to check
  • A simple card based signer like TAPSIGNER seems to be the lowest barrier to entry way to externally sign - recommend this over dedicated hardware device?
• Smaller amounts can be signed single-sig with users app key
• Automatic encrypted cloud backups of xpubs / app key for switching devices / backups / recovery.
• Need the ability to rotate new keys in and out
  • Use smart rotations with delays and notifications
• Social recovery? If user lose both of the keys they hold
• Seedless
• Ability to connect to and use your own node
• Accounts using BIP44 so users can manage their finances better.
• Timelocks - for example a lock preventing the third-party key from signing for x amount of months / years etc. (see Green wallet)
• Covenants?
• Taproot features: FROST, allow multisig to revert to single-sig after x amount of years (good for inheritance)
  • Taproot firist - makes P2TR address by default
• Watch-only wallets (no UI to craft transactions)
• Inheritance
• Privacy (app ideally collects minimal knowledge, could there be a way to prevent the third party from knowing my balances unless absolutely necessary?)
• Possible to recovery in other bitcoin savings wallet
• Emergency lock-down option in the app
• Dummy accounts (to prevent $5 wrench attack)
• Biometrics are okay to access the app but signing operations should be done with only PINs / passphrases / passwords.
• Hardened addresses? Maybe okay with seedless model.
• Gap limit UX
• Tor (not as big of an issue as when using lightning)
• Companion FOSS recovery tool in case app provider disappears

Once this reference design is done we should explore a reference design that has both savings wallet and daily spending wallet features included.

Resources

• https://docs.keys.casa/wealth-security-protocol/
• https://wallet.build/
• https://unchained.com/
• https://nunchuk.io/
• https://tapsigner.com/
• https://suite.trezor.io/
• https://www.ledger.com/ledger-live
• https://mycitadel.io/
• https://bitcoincore.org/
• https://github.com/wild-kard/arctica
• https://bluewallet.io/
• https://blockstream.com/green/
• https://sparrowwallet.com/
• https://revault.dev/
• https://www.bitcoinkeeper.app/

[GBKS]

Great, looking forward to see what you'll come up with. Looking at your list, I think the current page already covers the first 9 points, so seems like the basic setup is there and you are looking to detail out certain aspects further.

Maybe this could be broken down into several mini projects, where you focus on one area at a time. For example:

• Inheritance (via time locks?)
• Social recovery
• Key rotation via FROST (the page already has UI but does not explain how it works)
• Security

Feedback on a few points:

1. Accounts - why on-chain overhead and not do this as a UI layer?
2. Watch-only wallets - is this for observing balances on other wallets the user has? Does not seem central to this reference design
3. Is gap limit UX important for a wallet that does not expect frequent transactions?
4. Recovery could expand the desktop recovery tool Stephen is introducing in his backup revision

Since there's a third party involved (the auto-signer), it might be interesting to expand on that relationship. Block is designing something very similar (can't find that recent blog post about their recovery model). I think it would be good to consider whether our reference design is mostly the same, or how it differs based on our design principles, and a potentially stronger focus on open-source (maybe the auto-signer is also available as an Umbrella app or a one-click Digitalocean droplet?).

We could also do a brainstorm/jam session sometime to toss around ideas, if you'd like.

[Bosch-0]

so seems like the basic setup is there and you are looking to detail out certain aspects further.

Yeah that's the plan!

Good idea, want to keep the rollout of content structured so I am not going back and re-writing things.

Accounts - why on-chain overhead and not do this as a UI layer?

Yeah it would be UI layer only using BIP44 which just segments things things it doesn't create extra overhead. Also with descriptors BIP44 accounts can easily be backed up and used in recovery.

Watch-only wallets - is this for observing balances on other wallets the user has? Does not seem central to this reference design

Mostly yeah, but could also have a wallet that can sign and a watch-only version of that wallet in the same app the same as Green wallet has.

Is gap limit UX important for a wallet that does not expect frequent transactions?

I'd say it's mostly important when recovering a wallet like this not so much in generating new addresses. Will elaborate on this further as I get to it in the reference design.

Recovery could expand the desktop recovery tool Stephen is introducing in his backup revision

Ahh yep I actually missed that point! Added to OP. An open source recovery tool is definitely a requirement.

There is a link to all of Blocks post in the resources of OP. Good suggestions, I also had this other idea about a 'headless signer' where the third party signer does not interact with the front end at all and simply shares an xpub with the user and they can use it in any multisig client they wish (an issue I have with Casa for example is that they aren't FOSS but with a headless signer you get the benefits of collaborative custody whilst enabling you to use FOSS products like Nunchuk. Planning on writing an article explaining this concept some more.

I pinged Ryan from the Block wallet team to chime in on this discussion. I'm really liking their design for the balance of UX / security atm - hoping I can offer some insights to them also whilst exploring this!

I'm down for a jam session on this, next week sometime? Might make a savings-wallet channel in Slack to to discuss all things relating to bitcoin savings apps like this.

[moneyball]

Other FROST benefits:

1. Improved privacy (on-chain footprint is single sig indistinguishable from other wallets + 3rd party key signer won't learn of payments made that it doesn't sign)
2. Off-chain key rotation. If user loses a key, they don't need to do an on-chain transaction, saving time and fees (in the future this could save dozens of dollars).
3. Ability to rotate keys on a regular basis to increase security.

Note that off-chain key rotation would not be recommended in a configuration where multiple untrusted entities hold the keys, as you need to trust each key holder that they destroy old shares. For a wallet that is delivered by a single vendor and only has 1 user, or high trust among signers, that it should be fine.

[Bosch-0]

Great in-depth overview of the space atm: https://bitcoin.review/podcast/2022/08/30/Episode-05.html