BitcoinDesign / Guide

A free, open-source community resource for designers, developers and others working on non-custodial bitcoin products.
https://bitcoin.design/guide/
Other
454 stars 96 forks source link

Inheritance content for the guide #1104

Open rabbitholiness opened 3 months ago

rabbitholiness commented 3 months ago

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.

GBKS commented 3 months ago

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

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 commented 3 months ago

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.