This is a fork of Adding a More Restrictive Long Term Savings Multi-Sig Wallet

Socially Robust #interdependent Backups

The following is some thinking on an approach to backing up secrets such as #cryptocurrency private keys, wallet #seeds or .ssb/secret or other.

Picture from a keysigning party

@Alanna speaking to your (super valid) concern about people dropping out and becoming inaccessible there are things that we can do with #bitcoin (and public-private key cryptography more generally) which we could not easily do with legacy banking systems or business processes.

I am imagining myself being the one meant to do a transaction in our group. I don't know half your real names. I don't have your phone numbers. If a couple of you just dropped off the face of the earth and we were on a 4-sig wallet, we'd just lose access forever. Not to mention the even more likely short-term scenario where someone's temporarily non-responsive or doesn't have their password handy and the transaction is blocked until they do.

So what I am saying is.... for this to work we'd need to all be prepared to take it a lot more seriously than "normal" banking security and "normal" group responsibility to one another. I hadn't really thought about it in those terms until now.

I think it's possible for us to have more signatories whilst also reducing the risk of locked funds through non-responsiveness of one or more of the participants.

Why?

In a nutshell there are many configurations of organisation which would require more signatories than two on an account.

A quick #walkaway tangent

In walkaway cory maps out a way in which people could make their backups in a really robust way. I believe he laid out a 7 of 21 for people to get their data back, I won't disclose more than that because: spoliers.

There are alot of neat things in walkaway. Sharding is not a scifi future though, it has been possible since the 90s - just not so common outside of cypherpunk circles.

@mix has built horcrux, @Kieran has recently built truename-index, at #dyne we have built secrets

I laid out just one potential schema using these tools a while back here for the #ssb #multisig wallet

I'll redo it here within the specific context of mmt and this usecase.

Aims

To design a robust (defined as reasonably inprobable to have total loss) backup proceedure with sensible defaults (we need to find out what these are) out of the box (needs to be easy for anyone).

Accessibility

Process needs to ensure that the responsibility of care is not excessive such that any one individual bares an imbalanced amount of responsibility in the case of loss on their part. We want to reduce associated anxiety whilst safely weaving a higher degree of interdependent security.

Vision

@noffle wrapped up this position very eloquently here which I share and informs

I have a notion, kind of like #interdependence, but maybe more like #cooperative-sufficiency ? I'm trying to figure out how to express that we provide for ourselves in a communal fashion. There's no "cloud" that powers SSB. There's no hard dependency on the internet. There's no hard dependency on github (haha, well.. not quite yet). The idea that we as a community can mutually provide each other with the things we need to thrive, without outside influences that have the capacity to manipulate due to our dependence. This is kind of radical in the tech world, and I think it's worth speaking up about & prioritizing.

(I added the hashtags)

... continued below

Schema

Say we have the following people as part of the longterm multi-sig due to just having people who are involved in recent active development. We follow our previously established multisig generation process

• @Alanna
• @mix
• @Dan Hassan
• @peg
• @Kieran

For a highly secure/restrictive set up we might have 3/5, 4/5 or 5/5.

In establishing a multisig wallet together each person has a seed. It is possible for someone else to use this seed to restore the wallet.

Sharding

Using an available tool each person within an organisation could then shard their seed and share these around. Each of the backup people could be people from within the ecosystem whome are known to the rest of the team. In the event multisig-signer-1 is unresponsive for an agreed amount of time, the rest of the team could contact 2/5 or 3/5 of their backups for their shard so they could be combined to recover the seed.

• multisig-signer-1
  | -- A
  | -- B
  | -- C
  | -- D
  | -- E
  |
• multisig-signer-2
  | -- F
  | -- G
  | -- H
  | -- I
  | -- J
  |
• multisig-signer-3
  | -- K
  | -- L
  | -- M
  | -- N
  | -- O
• multisig-signer-4
  | -- P
  | -- Q
  | -- R
  | -- S
  | -- T
• multisig-signer-5
  | -- U
  | -- V
  | -- W
  | -- X
  | -- Y

Consent and Responsibility

Part an parcel of all of this is that we need clear and accessible documentation which explains to participants how this all works and what their responsibilties are. In the above schema with have 5 primary key holders, each of whome have 5 backups making 30 people involved in the social backup of the underlying resource.

Early days, but I am imagining a future on ssb where there is an option, like Gatherings, which is populated with sensible defaults which could help to roll all this out auto-magically within ssb...

As part of the auto-magic roll out we could ask which of our friends would we like to send a private message to with the details and the README.

It would be a few extra options to click compared to the #electrum multisig process.

I believe @mix
has said something about seeing this, but I can't recall where...

Also linking back to the multisig ceremony review as that conversation seems linked to this one: %NlzCWis...

@Dan Hassan perhaps you're thinking about the ssb system which @Kieran has already drafted which where you can ask friends if they're happy to be your backup and when tey say yes you send out the shard?

Or were you thinking a different process.

5 backups making 30 people involved in the social backup

actually at most 30, at least it's 5.

e.g. I send a shard to myself via email, and 4 others to the other participants. I think "should I send myself one of the backups" is one of the interesting questions that came up talking to @Alanna while she set up her wallet the other night. I think maybe it's ok if you've got a 3/5 quorum for recovering seed? Anyway, I sent 2 of my 5 to some of you. That means the group has most of what they need, but they can't take control of my wallet.... but they can sign a transaction which drains the account, so that point it probably moot ....

yeah I'm converted - in groups of >= 5, just share your key with the other memebers. And don't ever let a quorum ride on the same plane!

@mix , one of the neat things we get out of the box with ssb is a client side key. We can therefore send people shards 'in band' (within ssb). Essentially what I am scoping above is a process where it is possible to do most of this process automatically by listing / ticking people from a selection list. ...

Likely I am sleep deprived and not thinking clearly though

@mix "yeah I'm converted - in groups of >= 5, just share your key with the other memebers. And don't ever let a quorum ride on the same plane!"

Ok, this is an alternate schema! You mean to say each member of the group shares a shard with the other members of the group. This is quite a neat alternative!

"one of the neat things we get out of the box with ssb is a client side key. We can therefore send people shards 'in band' (within ssb). Essentially what I am scoping above is a process where it is possible to do most of this process automatically by listing / ticking people from a selection list. ..."

To clarify what I meant here:

Working with ssb opens up opportunities which would be much more difficult to achieve with a typical client-server model.

Within the context of ssb and within the context of a group (like mmt or a friend network) we can say to a fairly high degree of certainty that a person is the person we think they are on ssb. The identity problem is a hard one, which seems to be a long way to 'being solved' baked into ssb.

Auditing

By baking a sharding distribution process into ssb it is now possible to audit automatically and in band (within ssb).

@mix
here you state:

"For this round I think I'd like to explore our due dilligence process - i.e. how do we check each others practice. If this proposal is accepted, I'd like to add a proposal about how we do that."

Which @Kieran also agreed with here

"Would also echo @mix's emphasis on the need for due dilligence, especially following our accidental overpayment. A clear workflow / process of how to check a tx when cosigning and the means to review by-gone tx's"

Mix you clarified

"oh sorry - by due dilligence I meant "how do I know Dan has actually sharded his 4/6 wallet seed, because if he loses it and I lose mine we're dangerously close to an unrecoverable wallet" "

By having a sharding distribution mechanism baked into ssb you'd do something like the following:

1. Shard the secret
2. Tick the recipients of the secrets
3. These recipients are invited to be secret holders (this invitation could be rich with info about what this means)
4. Recipients who accept are logged and updated to the originator (they may need to find others who consent to be secret-holders)

If the above were baked into ssb, then it is auditable.

@mix : "@Dan Hassan perhaps you're thinking about the ssb system which @Kieran has already drafted which where you can ask friends if they're happy to be your backup and when tey say yes you send out the shard?"

Further clarification. Yes, I am talking about @Kieran's tool. It's a yes AND... .as in, what does the existence of this tool now afford ?

@Dan Hassan not sure if I'd gone into this with anyone other than @mix so far but here's a git ssb link with some data schemas and other ideas on the secret sharing process within ssb, that could store not just your own ssb private key but could be a mechanism for easily sharing any secret...

Its the next thing I'd like to work on but I've not had the chance to do more than just scope it out so far.

@mix if that is what you meant, then - that is the yes AND.

Really, this is quite a profound feature...

@Kieran I am super excited to work on this with you!

My favourite thing about the thing @Kieran has designed is that you can share a secret in such a way that even you don't know what you shared later. As in encrypt it only with their public key then it's out of your hands and a person who gets your computer can't see it!

A.K.A Password Recovery

Struck me on a call today we've been talking about one implementation of a protocol level approach to decentralised password (secret) recovery.

cc: @mix @Kieran @rabble @Dominic

The suggested proto-protocol is in the process of being built by @Kieran which is being documented in Social Backups

@Alanna this is this background threaded discussion for what we started to call Reciprocal Secret Securing at the Retreat. Would love to see if you think it's a clear way of narrating/storying/seeing it's value and purpose...