Coin type 60 is forbidden

[Sorizen]

I'm trying to use snap_getBip44Entropy with "coinType": 60 (ethereum) in my Snap, but i've getting an error like Coin type 60 is forbidden while I connect my wallet to snap.
It works with "coinType": 61 ( ethereum classic ), but I need to use a 60 coin type.
My guess is that it might be a "4.0.0" version bug because snap was running on "3.0.0" version with 60 (ethereum) coin type.

[Montoya]

This change is intentional. Going forward, it will not be possible to derive keypairs for Ethereum. If you want to use Ethereum accounts in a snap, we will soon enable eth_requestAccounts intead.

[Electr1Xx]

@Montoya How then can we sign or send the transaction?

[Montoya]

You will be able to use eth_requestAccounts to connect to Ethereum accounts from your snap and initiate signing / sending the same way dapps do today.

[Electr1Xx]

I saw that “personal_sign” method exists but send transaction is missing in ethereum provider, or this method will be added soon?
Is there any timeline for when this will be added?

[Montoya]

We will have to get back to you about that. Can you describe how you plan to use it?

[Electr1Xx]

For my case I just need to send transaction. I suppose that I will use ethers js pass there ethereum-provider, get singer and call send transaction method

[Montoya]

That probably won't work from within the Snaps context regardless. I will check with the engineering team and get back to you on this.

[Electr1Xx]

Maybe you provide examples of how I can send a transaction from snap for example on ethereum chain

[Sorizen]

We will have to get back to you about that. Can you describe how you plan to use it?

My plan is to use the private key with the ring signature implementation in my snap. I must have private keys to sign the message.

[jbettenc]

I just realized this became a problem for us today as well. This change breaks our snap's encryption (using eth-derived private keys to encrypt payloads that can be stored externally from the snap). It will likely render our use case and integration useless, but I will need to consult with other team members once they wake up. I'm happy to discuss our use case and reliance on the ability to derive keys for coin type 60 more in private, but having no warning or heads up about this change is a bit frustrating, especially with snap deadlines coming up so soon.

[Sorizen]

I just realized this became a problem for us today as well. This change breaks our snap's encryption (using eth-derived private keys to encrypt payloads that can be stored externally from the snap). It will likely render our use case and integration useless, but I will need to consult with other team members once they wake up. I'm happy to discuss our use case and reliance on the ability to derive keys for coin type 60 more in private, but having no warning or heads up about this change is a bit frustrating, especially with snap deadlines coming up so soon.

Thx you for reply, it would be great if you will return such functionality. It would also be great if you add the ability to get the private key of the currently connected account, not the account's master key. This will be a more secure method of obtaining a private key.

[Electr1Xx]

@Montoya @jbettenc Do you have any updates?

[jbettenc]

@Montoya @jbettenc Do you have any updates?

We've been in communication and he is planning to talk to the engineering team today to see what can be done. He and/or I will update this thread when we have more information.

[Volendi]

@jbettenc , hi. Do you have any updates on it?

[boyuanx]

@jbettenc , hi. Do you have any updates on it?

Nothing yet. (I work with @jbettenc)

[jbettenc]

@Volendi @Electr1Xx @Sorizen Unless something changes in the really near future (highly unlikely), I have confirmed that this functionality restriction is locked in for the upcoming release. Don't expect it to be available to us at launch or in the near future after launch. There is currently no replacement for this missing functionality.

[Divide-By-0]

Hey, limiting wallet access to signing and sending makes new signatures like PLUME (ERC 7524) impossible. The industry standard (used by Ledger for instance) is to allow access to private key exponentiation as an API (i.e. pass a generator point g and receive g^sk out from the enclave). It's a fine decision to gate this API on a successful eth_requestaccounts, but will create incompatibilities if removed entirely in favor of only signing and sending.

[Mrtenz]

Hey, limiting wallet access to signing and sending makes new signatures like PLUME (ERC 7524) impossible. The industry standard (used by Ledger for instance) is to allow access to private key exponentiation as an API (i.e. pass in a generator point g and receive g^sk out from the enclave). It's a fine decision to gate this API on a successful eth_requestaccounts, but will create incompatibilities if removed entirely in favor of only signing and sending.

We want to avoid that Snaps are able to sign arbitrary messages (like through eth_sign), as this can be used to sign transactions as well. It sounds like exposing an API to receive G^sk would allow for something similar? But I don't know enough about ECC to fully understand it. We're definitely open to supporting this use case though, if we can do it in a secure way.

[Divide-By-0]

We expect g^sk to require the user to sign a prompt explaining what g is. In our case, since g is just the sha256 of message and pk, it's easy for a user to inspect those preimages of the hash and ensure they align with what they expect to sign.

Without a prompt, yes, you could generate an ECDSA signature of an arbitrary message m by generating a k locally, calculating r, requesting r^sk from the enclave, then hashing m to get hash(m) = e and multiplying by k^-1 yourself (terminology as of ECDSA wikipedia). Thus, we expect this API request to be gated the same as any other signature.

A secure way to expose a general API could be to allow user passed in r, then return hash(r)^sk from in the enclave and make this a public API within snaps. Hash functions permitted can be restricted to sha256 for instance (anything that doesn't end in a curve exponentiation should be fine).

[Mrtenz]

We expect g^sk to require the user to sign a prompt explaining what g is. In our case, since g is just the sha256 of message and pk, it's easy for a user to inspect those preimages of the hash and ensure they align with what they expect to sign.

Without a prompt, yes, you could generate an ECDSA signsture by requesting such an operation then adding e and k^-1 yourself (terminology as of ECDSA wikipedia).

Do you have any references (like for Ledger's API), or other resources, so we can look into this further?

[kenhkan]

Closing since the snaps team will not support this feature in the foreseeable future

[sehyunc]

@kenhkan Based on this discussion and others am I correct in assuming there is no way to access the private key, or any account data for that matter, for chain ID 60 (Ethereum) using snap_getBip32Entropy, snap_getBip44Entropy, eth_requestAccounts, or any other method available to Snaps or Metamask?

[kenhkan]

@sehyunc Can you explain more on what are you trying to accomplish? We will certainly not provide access to the private key specifically in the foreeseable future. For the third one, you can refer to the documentation here for eth_requestAccounts.

[larry0x]

@sehyunc Can you explain more on what are you trying to accomplish? We will certainly not provide access to the private key specifically in the foreeseable future. For the third one, you can refer to the documentation here for eth_requestAccounts.

In my case, I want to use the user's Ethereum public key, but not the user's Ethereum account address. My chain derives account addresses in a different way as Ethereum does, meaning for the same pubkey you get a different address, so eth_requestAccounts is useless for me.

[Divide-By-0]

Hey, limiting wallet access to signing and sending makes new signatures like PLUME (ERC 7524) impossible. The industry standard (used by Ledger for instance) is to allow access to private key exponentiation as an API (i.e. pass in a generator point g and receive g^sk out from the enclave). It's a fine decision to gate this API on a successful eth_requestaccounts, but will create incompatibilities if removed entirely in favor of only signing and sending.

We want to avoid that Snaps are able to sign arbitrary messages (like through eth_sign), as this can be used to sign transactions as well. It sounds like exposing an API to receive G^sk would allow for something similar? But I don't know enough about ECC to fully understand it. We're definitely open to supporting this use case though, if we can do it in a secure way.

One of the most secure ways to enable a good private key oracle (that would work for PLUME) is to allow the app to pass in x, then return sha256(x)^sk. Is that something you're open to?