backlinks:

Social Backups

Socially Robust #interdependent Backups

How Facebook tries to do it

Have you got a bitcoin wallet preliminary discussions

Telescope and Microscope preliminary discussion

backlinks 2:

How Facebook tries to do it, 2

@Kieran expressed a concern about having to store the secret until all the people confirm and the shards can be created and distributed.

So I think this is primarily due to the order in which things happen. I wonder if we can work it in somehow by rejigging the place where a secret is requested. For example, if the UI waits until everyone has agreed to join the cabal, and the cabal exists as an entity, only then is each prompted to enter their secret, therefore secret doesn't need to be stored anywhere and is never revealed.

This still leaves the possibility of one person entering their secret and just others not. That said, since we're assuming high trust, thats not an issue.

@Kieran
Raw thought:

Given that we are talking about peoples own systems and raw data is never transmitted to another computer - seems like we aren't storing something which wouldn't already be on the participants system?

Given that we are talking about peoples own systems and raw data is never transmitted to another computer - seems like we aren't storing something which wouldn't already be on the participants system?

My thinking is you'd have your secret in a password manager, it wouldn't be in a vulnerable location on your computer, like in a file in your root directory (that said, for some it may well be, a practice which we're trying to discourage).

It depends on what happens with the secret once its entered. If you enter it, and then it just shards it and throws it away, can the computer retain knowledge of that secret (in a cache or something)? If it does, then you're right, its on that persons system and thats a vulnerability anyway, regardless.

I don't think it would cache this value unless you specifically told it to!

I'm thinking, if you're entering the secret and it writes it to a file to be sharded later, there's a risk that, say I leave my computer open somewhere and someone knows where to find that file, eep! Exposure risk. That file could be encrypted, then you need a way to encrypt that isn't publicly available, like using a password. You could add a password to open the secrets app (something we should consider anyway, though I discussed with @Dominic and @mix and there are pro's and con's to this) and use that to encrypt the saved secret until its sharded.

Does any of this make sense? I think the interface aspect of entering the secret first is better, I guess I'm just thinking that handling secrets means we should be careful about how a piece of software holds onto it. I don't think it should at all.

It could be that you ask the person to input it at the beginning, immediately hash it and store the hash?
Then before completing the process, when all cabal members have agreed to conspire together, ask the person to enter again just to make sure, if it matches, then its the same secret, you delete the hash and shard the recently given secret.

@Kieran ... we have an odd assumption we can make, which is that the participant will have a pub/priv keypair due to having an ssb powered piece of software on their computer. There is no need then for something to sit unencrypted at that point as it can be encrypted to self. This of course does nothing to someone with physical access to the computer...

@Alanna yeah you're right, in the cabal format, from each person's perspective there is a contingency, which requires that entry of the secret and sharding are displaced.

For example, if the UI waits until everyone has agreed to join the cabal, and the cabal exists as an entity, only then is each prompted to enter their secret, therefore secret doesn't need to be stored anywhere and is never revealed.

Aye @Nikolai so this is what I was getting at above, where if you get the members to agree to being a cabal, then ask for the secret, no storage is required. I think this is the best solution.

Due to the nature of ssb there is still a timedelay in that one person may receive all other members shards before sharding their own. Personally I don't think this is an issue in a high trust environment.

@Nikolai to add context, @Alanna sketched a UI workflow to attempt to minimize 'returns to the keyboard', to basically enable people to not have to come back to check if the cabal is complete in order to enter your secret.

@Nikolai "For example, if the UI waits until everyone has agreed to join the cabal, and the cabal exists as an entity, only then is each prompted to enter their secret, therefore secret doesn't need to be stored anywhere and is never revealed."

@Kieran "Aye @Nikolai so this is what I was getting at above, where if you get the members to agree to being a cabal, then ask for the secret, no storage is required. I think this is the best solution. "

TL;DR

If we are building a BMW (Better Multisig Wallet) from the ground up, and a cabal is already existing - then we have an opportunity to make the multisig wallet and do the sharded backups all in one-ish step.

Is this direct to MVP? Not sure?

MVP use cases

We settled on:

1. SSB identity (individual's secret backed up among trusted friends, one-to-many)
2. Multi-sig wallet (everyone in the group wants to mutually back up each other's keys, many-to-many)

Examples of why (1) may be needed can be seen in Index of #DeprecatedSSBAccounts where we see some of the foremost "experts" in the network having this need (including me, twice). An example of (2) would be the instantiation of a collective multsig wallet. You can see more of our explorations of these steps here:

MMT: Let's create a bitcoin multisig wallet (async)

Review of Ceremonial Invokation of BTC Multisig Wallet

As mentioned in the TL;DR comment above, I think the steps that @Alanna has outlined above are a very solid first jump in the right direction. IMO, it can be simplified within the context of a collective multisig wallet where the cabal already exists.

Having re-read @Nikolai 's intial question I am not sure that I answered it directly... but will leave to stew for a bit

@Alanna "In the cabal example, each person has their own secret to shard amongst the other group members. Unless I am misunderstanding something? In the case of a multi-sig wallet, which is the use case we're designing around, I think each member has a different seed they need to back up. So the cabal gathers all these, shards, and distributes."

+1 . This is also my understanding.

To help refresh memories I suggest running through MMT: Let's create a bitcoin multisig wallet (async) to see the steps and the secrets from each participants perspective.

Worth noting the seed/secret only exists in a useful/functional way with the existence of all the other seeds + the logic (quorum and number of participants). So there is certainly something about TIMING here. Also interesting to consider that we can assume the logic has been determined and agreed OUT OF BAND (in a call, in loomio, in messages, etc) BEFORE setting about STARTING the multisig invokation...

So, with these assumptions with this particular usecase in mind, we can assume that people would be able to do their bit and shard their seed in one sitting and async... unless I am missing something....

Also interesting to consider that we can assume the logic has been determined and agreed OUT OF BAND (in a call, in loomio, in messages, etc) BEFORE setting about STARTING the multisig invokation...

What I mean by this is that when a person sits down to setup the wallet they will know

• how many participants
• how many signatories needed (quorum)
• the name (maybe?, perhaps the first to the intiation stage calls shotgun and has naming rights)
• sharding backup defaults / if they will do this differently...

@Nikolai "Or instead of 3. is there some gathering to stop each member of an N sized cabal having to store N-1 shards, emanating for all the other cabal member's keys?"

this is something which @Kieran and I have spoken about but we haven't sat down and figured out a formal proof for what all of this means - which I have taken on I think a bit with pb to review.

But, yes - what you are getting at is correct, but we have not expanded on implications and effects...

So in the case of sharding a multi-sig wallet are you/we/mmt saying:

1. Agree the cabal members, the min required members for the wallet, the min required shards to re-create a key
2. Each person share's their xpub (in a secure way) with the cabal
3. At the same time as 2. they shard their private key with the cabal

Very loosely, yes this is my understanding of the of the MVP.

It's useful having your detail and programming lense in on it as these are the details that we need to figure out.

@Alanna "I think it's still an open question if we want to only allow the interconnected cabal (where members share their shards only with the other members), or we also want to enable sharing with outside shardholders."

Within the next fortnight I plan to sit down and start mapping out a paper with various combinations so that we can add that to the considerations.

"I think if we enable both the "secret" and "cabal" use cases, you could still chose your own outside shardholders if you are part of a multi-sig by just using the "secret" option. So it would be up to the user. "

Agreed.

"I think we'd need to speak to a range of multi-sig users and see if they would be interested in only sharing backup responsibility among group members or with outsiders. "

Agreed with this also. I know from my experiences within mmt and the london crypto circle and a few other side projects I personally would like to see the possibility of a mix. In some cases internal-cabal makes most sense, in others all outside would make sense. In most case I think a mix of the two approaches would be the best balance.

Quick bit of #mmt archeology... lets remind ourselves only a few short weeks ago we were drawing cartoons about this stuff... we're now digging into the guts and making it real!

Have a look at these for a bit of eye candy

& some more by me

@dicey you might also be interested in this post:

group multisig, & same-as but with people

The work we are doing on Dark Crystal will inevitably interact with the development of ssb and groups and other protocol level advances.

TL;DR, the problem space you have identified is in the same neighbourhood as the one mmt is looking at

cc: #darkcrystal