social recovery wallets

[Husires]

I have read about this concept from this article and I will quote some points from it:


https://vitalik.ca/general/2021/01/11/recovery.html

To me, the goal of crypto was never to remove the need for all trust. Rather, the goal of crypto is to give people access to cryptographic and economic building blocks that give people more choice in whom to trust, and furthermore allow people to build more constrained forms of trust: giving someone the power to do some things on your behalf without giving them the power to do everything.

This gets us to my preferred method for securing a wallet: social recovery. A social recovery system works as follows:

There is a single "signing key" that can be used to approve transactions
There is a set of at least 3 (or a much higher number) of "guardians", of which a majority can cooperate to change the signing key of the account.
The signing key has the ability to add or remove guardians, though only after a delay (often 1-3 days).

If a user loses their signing key, that is when the social recovery functionality would kick in. The user can simply reach out to their guardians and ask them to sign a special transaction to change the signing pubkey registered in the wallet contract to a new one. This is easy: they can simply go to a webpage such as security.loopring.io, sign in, see a recovery request and sign it. About as easy for each guardian as making a Uniswap trade.

Will the concept of social recovery wallets be good for those who fear losing their wallet seed-private keys?

[pawanjain]

This could be provided as an option but should not be provided as the only way to sign transactions. A user should have both the options while creating a wallet

* Owning private key where the user is the only owner
* Social recovery

One thing that I personally don't like about the social recovery system is the 3 out of 5 guardians changing the signkey part.
It has to be at least a 4:5 ratio because the user will be sole person in the beginning to approve the guardians I guess.
These days the person we trust are the ones who cheat us. So the number of guardians and higher ratio, the better the security.

Even if the social recovery option is provided, I think most of the people will still choose the first option and control their addresses by themselves.

P.S : It just seems to me like a multi-sig combined with privatekey where multi-sig is able to generate a privatekey whenever lost 

[NotATether]

In a way, we already have such transactions in the protocol. They're called Hashed Timelock Conracts or just HTLCs for short. It's for making transactions on the condition that the sender has a limited amount of time to "finalize" the transaction being sent, or else it doesn't actually occur.

We basically just make a normal transaction with the entire balance to the guardian but we define a value really far in time such as 100 years, or some other big value that exceeds your lifespan, and we also SHA256 hash a secret number.

The guardian's wallet will require the other person to send the secret number which made the hash, within the defined time period. Now this number can for example be revealed in a will so that the condition can be fulfilled and he transaction can take place immediately. It is better than using 1-2 (or worse, 1-N) multisig where you constantly have to trust the guardian not to defraud you while you're still alive. And whose going to risk putting such a big trust in all their money?

The only problem I see with this scheme is because we're locking the transaction inputs in place, upgrading the signature algorithm to resist cracking, and freezing addresses using the old algorithm, will lock the transaction money in there forever. It's a very rare scenario.

This can be mitigated by only setting the Locktime field of transactions to some time after your expected lifetime, instead of using HLTCs, but this doesn't protect from a sudden accident/death in which case there would be no Locktime transaction, since you didn't foresee the need for one beforehand.

[pooya87]

Possible? Yes.
Good idea? No, not even remotely.

Ideas such as this one are like taking steps backwards undoing everything we've worked for. Bitcoin was created so that people don't rely on any third parties for their money, whether for storage or spending it. People who can't do that and have to rely on third parties should not be using bitcoin in first place. We already have a much better option than "social recovery option" for these people called the "banking system".

[PrimeNumber7]

In a way, we already have such transactions in the protocol. They're called Hashed Timelock Conracts or just HTLCs for short. It's for making transactions on the condition that the sender has a limited amount of time to "finalize" the transaction being sent, or else it doesn't actually occur.

I don't think HTLC can do what is described in the OP:
*'signing key' changing 'guardians' after a time delay
*'guardians' changing the 'signing key'

I could see a HTLC transaction invalidating a 'signing key' or a 'guardian' however I can't see a new one being installed without an additional on-chain transaction no later than at the same time the 'closing' transaction is confirmed. The time delay in changing the guardian would be especially difficult with HTLC transactions, and would be pointless without some kind of notification to the 'guardians'.

[NotATether]

I don't think HTLC can do what is described in the OP:
*'signing key' changing 'guardians' after a time delay
*'guardians' changing the 'signing key'

I could see a HTLC transaction invalidating a 'signing key' or a 'guardian' however I can't see a new one being installed without an additional on-chain transaction no later than at the same time the 'closing' transaction is confirmed. The time delay in changing the guardian would be especially difficult with HTLC transactions, and would be pointless without some kind of notification to the 'guardians'.

You are right but remember that the signing key can just be a plain old private key for an existing address type, the guardians changing and stuff can be accommodated for by making the timeout smaller so this increases the frequency we make HLTCs.

At any point we can share the secret input to the hash with whoever we want so the changing of guardians happens in the mind, when nobody else knows the secret yet.

[pooya87]

I don't think HTLC can do what is described in the OP:
*'signing key' changing 'guardians' after a time delay
*'guardians' changing the 'signing key'

Translation of the picture posted in OP to a bitcoin smart contract:

Code:

OP_IF
  <pubkey> OP_CheckSig
OP_ELSE
  <locktime> OP_CheckLocktimeVerify OP_Drop
  <user_signing_key> OP_CheckSigVerify
  OP_3 <guardian1_pub><guardian2_pub><guardian3_pub><guardian4_pub><guardian5_pub> OP_5
  OP_CheckMultiSig
OP_ENDIF

OP_CLV is for the delay mentioned in OP.

[gmaxwell]

As typical the description is overly convoluted. As a result pooya87's script can be simplified.

In the description the signing pubkey can take the coins completely.  That means that there is _absolutely no purpose_  to trying to delay the signing key from changing the "guardians":  The operator of the signing pubkey can just take the coins and move them to a new location (potentially with new guardians.).

In the description the guardians aren't delayed at all, this seems stupid to me, given the purpose is recovery but it's what is described.

As a result,  the script just turns into a 1 or (3 of 5) multisig or a 3 of 6 weighed threshold with the first key having weight 3.

W/ taproot this could be implement so that in the likely case where the guardians aren't required the txn are indistinguishable from a normal single key txn.

It would probably make sense to stick a couple week CSV  in the guardian branch so that if your guardians are compromised you can still prevent them from stealing the coins-- and if it's a recovery mechanism the delay won't matter much.

[gmaxwell]

Even on Bitcoin, there aren't any user friendly software (except usual multi-sig) to create script and create it's corresponding P2SH/P2WSH address.

It's really hard  (impossible?) to make generic software to handle arbitrary scripts.

But this case can be done with existing standard software, just inefficiently:  Make a 3 of 8 multisig where the primary signer controls three of the keys.

[Porfirii]

Possible? Yes.
Good idea? No, not even remotely.

Ideas such as this one are like taking steps backwards undoing everything we've worked for. Bitcoin was created so that people don't rely on any third parties for their money, whether for storage or spending it. People who can't do that and have to rely on third parties should not be using bitcoin in first place. We already have a much better option than "social recovery option" for these people called the "banking system".

Indeed, it seems like it actually went against the motto "don't trust, verify".
I suppose that there is nothing bad with sharing new ideas and social recovery wallets may fulfill a use case in the market, as a niche; I don't think they will be the main use case ever because the truth is in the numbers: better to trust them before trusting third parties.

[NotATether]

Not exactly user friendly, but it's better than use library (such as BCoin). Do you think it's still really hard?

Then you're basically making a compiler similar to GCC except for bitcoin scripts. You have to additionally check for semantic errors which involves making symbols out of all the opcodes, assign even more symbols for combinations of opcodes that go together and signal an error if you somehow manage to illegally use an opcode somewhere or pop past the end of the stack.

I imagine such a codebase is going to be very hairy. I'm too afraid to check GCC's to estimate how hairy yours would be 

[BrewMaster]

Not exactly user friendly, but it's better than use library (such as BCoin). Do you think it's still really hard?

Then you're basically making a compiler similar to GCC except for bitcoin scripts. You have to additionally check for semantic errors which involves making symbols out of all the opcodes, assign even more symbols for combinations of opcodes that go together and signal an error if you somehow manage to illegally use an opcode somewhere or pop past the end of the stack.

I imagine such a codebase is going to be very hairy. I'm too afraid to check GCC's to estimate how hairy yours would be 

the hardest part that makes it impossible to create such software is the challenge of being able to automatically figure out what kind of scriptsig to create that spends the given script assuming it is not one of the standard (predefined) scripts that we know of. this becomes even harder when the script is more complicated, like having a bunch of IFs in it.

otherwise checking semantics, validating a script and disallowing invalid OP codes,... are easy.