search

Loopring / protocols

A zkRollup DEX & Payment Protocol
https://loopring.org
332 stars 122 forks source link

[hebao] discussion on guardian grouping #779

Closed dong77 closed 4 years ago

dong77 commented 4 years ago

The idea is to allow users to group guardians into more than one groups, certain actions are approved with ceil(num_of_groups / 2) instead of ceil(num_of_guardians / 2). Within each group, ceil(num_of_guardians_in_group / 2) approvals are required.

Why do I propose this approach? In my case, most of my guardians know each other, To prevent them from a conspiracy, we can group guardians who may know each other into a single group so their weight only matters in that particular group.

letsgoustc commented 4 years ago

The idea is to allow users to group guardians into more than one groups, certain actions are approved with ceil(num_of_groups / 2) instead of ceil(num_of_guardians / 2). Within each group, ceil(num_of_guardians_in_group / 2) approvals are required.

Why do I propose this approach? In my case, most of my guardians know each other, To prevent them from a conspiracy, we can group guardians who may know each other into a single group so their weight only matters in that particular group.

Suggest to add the following groups first: Transfer Group: Allow guardians to manager money transfer. Recovery Group: Allow guardians to recover wallet owner. Dapp Group: Allow guardians to manager dapp calls.

And also we should consider not only ceil(num_of_groups / 2) to grant permissions, but also allow user to increase the bar. For example, maybe for big money transfer group, we may need above 2/3 guardians to grant permission.

Brechtpd commented 4 years ago

I think some form of grouping could be useful, though maybe assigning weights manually can also be beneficial. In both cases the UI gets more complicated for users so finding a good balance is important.

Another solution to this problem could be something like this:

People don't know if they are part of your social recovery, and even if they know they can't create the Merkle proof because they don't know all the values of the leafs.

I also think social recovery is more of a last resort kind of thing. Just for managing your own wallet you don't really want to use signatures of other actual people if not necessary because of these trust issues. Because of that, I think it may make sense to only allow social recovery after something like 1 month the wallet hasn't been used (which would mean the original owner lost access to his wallet for some reason). So something like a special Recovery Group could make sense.

In all other normal cases I would think the guardians are largely directly controlled by the user itself:

In a scenario like this, I would assume wallet owner + 2FA + email to be less secure than (wallet owner + )hardware wallet even though the first option has more guardians. So some weighting of guardians probably make sense.

I think it would make sense to allow a single guardian that is as secure as a hardware wallet to configure/spend pretty much anything on the smart wallet without limitations (perhaps as an extra security also the 'hot wallet' wallet owner needs to sign to guard against the stealing of the paper copy of the recovery code of the hardware wallet, but that should be very unlikely anyway).

dong77 commented 4 years ago

The Merkle tree approach is interesting and preserves privacy to a certain degree. The concern I have is that the list of guardians needs to be 100% available to the user. The current approach saves a list of guardian address to Ethereum, which guarantees accessibility and availability. Another benefit is that adding guardians can be an interactive approach so it will be really helpful for user adoption.

We cannot assume people have a hardware wallet, at least the majority of our targeted users don't (but for those who do have hardware or paper wallet, we should allow these guardians have more weights).

2FA is really interesting to me if it can be implemented in smart contracts (it should not be treat as a guardian though). I would say if 2FA is available, it should be used whenever the user wants to use its owner private-key onchain to transact onchain as 'msg.sender'-- all offchain or meta-transaction's timing cannot be guaranteed, so 2FA will become invalid very soon.

We certainly don't want users to create or customize guardian groups, otherwise, the UX is more challenging. For Chinese users, I would recommend the following predefined guardian groups:

A group is established if the group has at least 1 guardian. The total_weight of all groups is the sum of all established groups. And the wallet will require floor(total_weight/2) + 1 approved weight for recovering its owner.

A group can have as many as 10 guardians and is considered approving a transaction if floor(num_guardians/2) + 1 approved the transaction. Each guardian can only belong to one group.

The grouping idea assumes:

dong77 commented 4 years ago

Here are some information regarding 2FA.

"In short: probably not (to use 2FA with smart contract)

But if we are talking about traditional centralized 2FA, the App will certainly support it.

dong77 commented 4 years ago

After a second thought, I propose the following design.

Social Recovery Guardian Group

To recover using social recovery, ⅔ groups must approve the recovery request, inside each group, floor(N/2) + 1 must approve the request.

Self Recovery Guardians

To self-recover, 2 self-controlled guardian addresses must approve the request if N >=2, or 1 address must approve the request if N == 1.

Self-recovery guardian addresses must be EOA, not contracts.

Brechtpd commented 4 years ago

Here are some information regarding 2FA.

"In short: probably not (to use 2FA with smart contract)

This doesn't mention some interesting ways data can be kept private like ZKPs. :)

It should be pretty easy to create a ERC1271 smart contract that allows a user to use a password to approve a meta tx (using a proof that you know the password so the password is kept private), which would be an interesting and completely decentralized guardian to have without having to store any data anywhere. 2FA I don't know enough to be sure, but could perhaps also work.

dong77 commented 4 years ago

implemented by https://github.com/Loopring/protocols/pull/828