Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inheritance content for the guide #1104

Open
rabbitholiness opened this issue Jul 13, 2024 · 2 comments
Open

Inheritance content for the guide #1104

rabbitholiness opened this issue Jul 13, 2024 · 2 comments
Assignees

Comments

@rabbitholiness
Copy link
Collaborator

In the context of publishing the Inheritance Wallet reference design, @moneyball brought up the point that using relative timelocks can be costly for the users and, more importantly, that since their isn’t a clear best solution for inheritance, other approaches should be described as well.

I agree with the basic criticism here. So the goal of this issue is to to clarify and to outline the additional content around inheritance. An approach that I think could work would be to:

  1. Add a dedicated and more explicit description of the tradeoffs to the reference design. The cost of refreshing relative timelocks is highlighted on the “Custom Spending Conditions” page, but is not reiterated in the reference design.
  2. Create an inheritance subsection in the “How it works” section of the guide. The overview page of the inheritance section would outline the different approaches and their main benefits/tradeoffs. The child pages would describe how keys and backup material can be distributed in different scenarios like the ones mentioned below. They would also list existing examples:
    • Singlesig.
    • Collaborative/multi-party multisig.
    • Self-custodial multisig.
    • Advanced techniques like timelocks, pre-signed transactions that can be employed in many of the above mentioned scenarios.

I'm open to other and/or additional suggestions as to how to structure this.

@rabbitholiness rabbitholiness self-assigned this Jul 13, 2024
@GBKS
Copy link
Contributor

GBKS commented Jul 15, 2024

That makes sense to me. I wonder what a good way is to break this down? You could go by:

  • Technical approach: An approach is to use PSBTs and therefore user flows are like this and like that...
  • Risk scenario: The highest risks are loss of keys and collusion, which are best mediated this way and that way...
  • Social dynamics: Most people that have this problem have X family members and are in situation Y and therefore...
  • User flow: Key setup is most convenient via approach X, key replacement is best via Y...
  • Economics: For inheritance less than 100x annual average transaction fee, approach X is best...

Probably more dimensions to this. Maybe products and approaches can be defined by what they optimize for? One product is about minimal cost (no hardware devices, no time locks...), another one is about preventing collusion (kids scheming with the lawyer...), another one about robustness... (software/hardware going away over the years, only use established standards)? Not really sure, just thinking out loud in the hope that it helps.

@moneyball
Copy link
Contributor

I'd also suggest studying Casa, Unchained, Nunchuk, and any other existing inheritance solution. I believe each one's design is distinct with different tradeoffs. BDC/BDG should determine whether we think all 3 are legitimate/should be recommended in certain cases, and if so, do that, along with why and pros/cons.

I'm also aware of potential solutions which are similar to what Michael proposed but don't require continual on-chain transactions to reset a relative timelock. This would be a pre-covenant design which presigns transactions and deletes the private key. I believe Liana has implemented something along these lines (but not for inheritance). There's pros/cons to this approach as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants