Topic: social recovery wallets (Read 235 times)

Bitcoin Core (and other full node software) can detect the script is invalid or non-standard, we could use the source code to check whether the script is valid or not.

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.

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 

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.

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.

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.

Translation of the picture posted in OP to a bitcoin smart contract:
OP_CLV is for the delay mentioned in OP.

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.

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'.

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".

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.

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 

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






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