@axe You got it right using chainID around peerHash, but it dont needs to be verified in a leaf basis, it could be incorporated in the hash path of publicHash. We could make that, as publicHash depends on peerHash, the peerHash could depend on chainID and executeHash, which would tie all to only sign for the correct chain, because the peerHash will “never” match if the chainID returns incorrect.
However this might lead to an problem, because in case of a chain split, the recovery contract would only work in the chain that didn’t changed the id - this is also true for how you implemented chainID.
So, chainID only should be checked against signatures, so perhaps we could start using EIP-712 with the new chainID from EVM, I will check that. For now we are using EIP-191 with validator address as the recovery_contract and now also using chain ID inside of the application parameters.
I also noticed that, due the lack of information on the EIP, you implemented signature checking in your own way. So I also added this missing part of the specification on how the messages to be signed should be constructed.
I updated the account-contracts to match current version of ERC-2429…
Some changes I am considering:
Reorder parameters of the signature to order them by their context,
Enable bigger thresholds by counting secretCall authorizations on advance, or by enabling multiple interations on execute
I didn’t consider the case of a chain split. This could be a problem if there is a recovery process running, to all other cases the user could simply set a new configuration following the proposal definition.
For this case, probably we need to make some tradeoff between protection for a replay attack (I think there is a small opportunity for this type of attacks given that of each recovery the proposal mandates a new “recovery tree” and all hash are bind initially with the contract address + nonce).
I feel that people using this proposal without full notion about the internal mechanism in a split event, could lose the ability of recovery in the “right” chain. (or in all chains for that matter)
After reading more careful the EIP1344, I did not came to a conclusion about the solution.
The solution is not use chainID in the hashing path or in the leaf check. They are not needed in the hashing, what we want to prevent is a single execution to be replayed in other chain.
This problem only occurs in presigned messages using EIP-191 v0, for direct transactions the EIP-155 already secures that.
I included the protection there, just like you suggested, so I can confirm with confidence that this specification is not vulnerable to replay attacks on presigned messages or transactions.
Your implmentatation also used chain id in the signature check, but it was also using in the leafs.
I will still see if is possible using EIP-712 (which is EIP-191 v1) with EIP-1344, because it already have the chainID incorporated in the standard, meaning that wallets would seamlessly sign messages just like transctions, passing the correct chainID, and it would not be stuck in case of chain splits.
Ah BTW, I changed bytes ensName to bytes32 ensNode as I noticed it was nonsense to reveal the plain text ens name, instead the merkle tree should contain the ensNode in the leaf composition.
Thanks for the diagram, I dont want to include images attachments because they are horrible to edit. But I liked the idea of diagrams anyway, so I added it as “mermaid”, see here: https://hackmd.io/@3esmit/rJ4YBV_JI#User-secret-data-hashing
After reviewing the doc in the link, i think it should made clear that as a peer in the recovery process a user can eventual have there’s address associated with the recovery account. So it’s good practices to select a “fresh” address to be a peer.
I will reimplement the proposal, but will probably be very similar to yours.
Great suggestion, @axe. I will add this to the doc, and also try to standerize the recovery help request message.
Regarding your old suggestion on using the user private data secret as a private key, I am reconsidering it, but still keeping the merkle tree of friends. Therefore, the system will be exactly how it is now, but the smart contract will get rid off the commit-reveal scheme, replaced by the semi-private key.
I added weight to the addresses to approve, so it can be used for trustless recovery with KYC services, where the KYC operator would have a bigger weight (or total) from threshold, but the user also dont want to fully trust only a KYC operator, but also a large set of their friends.
Also, I changed the execute ABI, now it must count the approvals at moment the calls are approved, not during execution. At execution it only reveals the threshold.
I am tracking the discussion in both places, so you can post here or there as you want, but I will reply at the same place. After the PR is merged the discussion would remain only here.
@jpitts can you mark this into identity ring? also there is ERC 2429 built after the discussion here
Or maybe its correct to wallet ring. Not sure, you decide what fits better. Thanks!
Could someone give me an example, what the account contract (the target of recovery) would be in ERC 2429 recovery?
The account contract can be any contract, but how does it gets input parameters, how does it return output parameters?
Could recovery used to recover a secret like the mnemonic of an HD wallet?
thanks!
The target of recovery can be any smart contract that accept a call from the recovery system. You can define the form and content of that call so that’s can suit you recovery context.
Think as a proxy that will execute some code and call your smart contract.
I don’t follow your question about the HD wallet, but from what I understand you want to recovery a wallet that have no code on chain? In that case only the Private Key can help and you should not save in any form the private key related information on chain.
I can work in a set of examples to make this part of recovery more clear.
Thanks! What I cannot really see without a concrete example, how one call to a recovery contract, made during recovery, can be used in a ‘sticky’ way, that is, it restores access to some service/account that will stay for longer. The only way I can imagine that is that contract call returns some secret which your wallet stores, but I feel that is not the intended use.
I did not have the time to make examples in the implementation. Hopping to make something by the end of this week.
You are not bound to one recovery style like changing the owner of a smart contract wallet. It really depends one your requirements. The system is very agonist about that, you can for example imagine a recovery that transfer all the found to a new account.
When you are setting a recovery, you are setting a group of signatures, let call then people, that eventual will approve a transaction.
If you see more careful that tx can be any method call. So your example is valid. You can have a contract that waits for a call from the recovery system. The arguments of such call is up to you. A secret is valid as any other value. You can for example pass the root node of the Merkle tree so you can react different.
This don’t changes the overall behavior, but it reduces net gas cost, and makes things a more private (as for the world someone set as guardian just an address without code, could be UTXO, could be anything)
I’ll open a group to build this for ethereum network users, agnostic of any app, like a CC-0 PoC dapp, which later can be properly built into the wallets willing to implement it.
Anyone willing to contribute is welcome, you can join by answering here or sending me an e-mail at 3esmit at gmail dot com with title Ethereum Social Recovery, and telling how you would like to contribute. I’ll inform here about a call to discuss the topic.
