You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
I'm open to other and/or additional suggestions as to how to structure this.
The text was updated successfully, but these errors were encountered: