Logics of Coconut Death for Dark Crystal Development

mmt ran a Coconut Death Experiment role playing a scenario where a secret owner becomes incapacitated. This scenario has come up as we begin Dark Crystal Development.

This thread is to gather our thoughts to considerations in designing for this scenario. It may be the case this is not within the scope of v1 of

cc: #darkcrystal

Assumptions?

Grace has shared their .ssb/secret with 5 friends.

At some later point Grace has become incapacitated.

Some number of the 5 friends is aware that Grace has become incapacitated.

What next?

Without getting into the technical details we can make some social guesses and scenarios which may happen. We can guess that word will get out that Grace is incapacitated. There may well be some type of announcement about Grace being out of action. Let us assume then that some high percentage of the shardholders are aware Grace is out of action. Socially it would make sense for those who have participated in receiving a shard from Grace to know - hey, I probably need to do something now. Quite likely in the event no other course of action has been laid out there would be human gossip amongst the social network about what's up with grace and also asking eachother if anyone else was a shard holder and if anyone knows what happens next.

In Cryptoasset Inheritance Planning: A Simple Guide for Owners Pamela really drives home that it is not enough to just get the private keys to the end recps (heirs?). Will they know what to do with it? Will they have the concepts, the skills, the context?

What is suggested is to assign Executors and Technical Aids. Within this context we should be thinking not just about getting key backed up, but setting up social circles and social fabric which will be able to make use of the thing being passed on.

Perhaps Executors get given a private message which is readable after decryption which stipulates a course of action in the even of coconutting. Perhaps there are hash links to people Grace trusts to offer technical expertise. etc - you see where I am coming from here...

cc: @Alanna @mix @kieran @peg

i know i am big sky thinking - so it is with self awareness that I am suggesting this.

I think we're at a point where everyone should read this.

https://www.amazon.com/Cryptoasset-Inheritance-Planning-Simple-Owners/dp/1947910116

It can be read in a few sittings and basically contains a recipie for thinking about passing on crypto in event of death.

alot of the logic and process is invaluable and I think will really better inform ourselves as to successful patterns of estate management from the old world.

The good thing about this is that it maps 1:1 onto patterns people are used to

e.g. assigning an executor (ideally a pair), thinking through grief etc

I am sure it might be tempting to say this is not the right time - but given we are at the stage of encoding defaults - it would make sense to basically just mirror what the legal defaults are in most jurisdictions

i.e

assign differentiated trust to different parties - i.e. executor, figure out people who can fill the roll of technical aids to the executors etc... these are just the two main ones which I would say we need to think about.

I would encourage us all to apply our brains to that work and follow the steps as it will strengthen our overall input.

cc: @Alanna @kieran @mix @peg

backlinks:

Pamela Morgan on EpiCenter
Cryptoasset Inheritance Planning: A Simple Guide for Owners

I have seen questions come up in this thread which are well thought through and researched in the book (by a lawyer who is technically proficient Andreas M. Antonopoulos is her CTO)

e.g.

• Do we also need to store identities of the other shardholders? Dan once mentioned a security mechanism whereby shardholders do not know each others identities and then broadcast their identity in the case of a certain condition (the secret being lost). I would ideally like not to store them with the shard.

• people receiving secret shard are unaware of everyone involved, to include more, just add to recps. @Grace can choose to make everyone in the group hidden of visible to the others, or just make it so only one other person knows, or just themselves.

• i'm keen to go super simple with our v1
  I tihnk if I've understood everyones suggestions the main things to decide are :
  do I record who I sent shards to onchain (I think yes)

hey @dan hassan one thing we discussed in our meeting was that the coconut death case is the second case we're going to solve. More specifically, it's actually a bit more complex, so we're deliberately not starting with it.

This isn't to preclude others exploring this case, in fact it's good to run ahead, I just wanted you to have a heads up that I won't be engaging with it till we have the simple happy case published and tested with humyns

@mix noted!

I think I've mentioned this via signal channel.

Part of my job (that I have self-assigned) is to absorb everything from within the ecosystem surrounding us as we can. I get excited about both people, projects and things and it adds to the expansive web of connections. This is super handy at the getting started phase.

My suggestion to read this book is not about general excitement.

It is about strategic use of our limited time :) I'd say at least one of @peg
@kieran
or you should read the book - it's useful even for v1. All it may mean is the addition of a field for a note to a primary shard holder. Or it may mean we decide not to change the current v1 - but at least we will be doing so from within an informed position!

I am going to try and pull out the recipie sheets and further digest them into ssb parsable chunks so y'all can hopefully see where I am coming from

Here is a link to a copy of the book which you can open with calibre app:

https://keybase.pub/danielsan/reading/Cryptoasset%20Inheritance%20Planning_%20A%20Simple%20Guide%20for%20Owners.azw3

Placing the pdf blob here: Cryptoasset-Inheritance-Planning_-A-Simple-Guide-for-Owners_compressed.pdf

Yes - that's exatly right @peg. What I love about the book is it really breaks the process of passing information to people in difficult situations. So much of this is about clear communication. This might not change the plumbing but can certainly be added to the interface as a note. Also conceptually having a notion of a 'main point of contact' will inform the design.

RE: Pamela recommending ssb or not - maybe not now - but imagine there was a wallet which had it baked in for free, which to the human using it looked and felt no different than learning how to use electrum or samouri...

Anyway - at this point worth dumping the learnings from the coconut experiment

%M/6NE1+...

Reconstructing seeds from shards

@Alanna did the shard combining during our last meeting. Lots of issues came up. Which is a good thing!

• There is a lot of confusion created around that multisig wallets having different amounts of required signatories (eg: 4 of 5) and sharding keys can have different amount of required shards to reconstruct (eg: 3 of 5).
• We could each choose the amounts of required shards when sharding our seeds. Which also lead to a bit of confusion. Although maybe the confusion was more about a star trek joke!? Dyne.org's implementation of secret sharing gets around this by forcing us to use a fixed number of shards (3 of 5 i think). This keeps things simple, but comes at the cost of the flexibility of the tool.
• Imagine being in alanna's position of being given a load of shards from different people and for different people's keys and trying to keep track of them all. Confusing.
• @mix also mentioned there could also be confusion about which implementation of secret sharing people used (was it truename or dyne?).

Despite all this, alanna recovered dans seed pretty quickly. A good thing is that its pretty easy to tell when its done right - you suddenly see a bunch of english words instead of random characters. But this might have not been so obvious if we were sharing a key which looked random instead of a seed.

We now have dans seed, but this is not the end.... our adventures in getting back our 50c are continued in this thread with wonderful pictures

backlink:

Brainstorming coconut-related scenarios