MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
11.95k stars 4.88k forks source link

eth_signTransaction on Metamask #7644

Closed iris112 closed 3 years ago

iris112 commented 4 years ago

Hi. I'm getting RPC error when i try to sign transaction using metamask. That is our important features. But currently i think metamask is not working for this api. Is that correct? How can i solve this issue using metamask?

Thanks. Regards.

jennypollack commented 4 years ago

Hey @iris112 are you still having this issue/can you provide more information?

luziusmeisser commented 4 years ago

It would be great if MetaMask could be used to sign transactions without sending them to the network. In particular, MetaMask should support the "send offline" feature of my ether wallet (https://www.myetherwallet.com/interface/send-offline). Currently, when trying to use "send offline" with a MetaMask account, metamask signs the transaction and sends it to the network. When doing the same with a ledger, the ledger correctly signs the transaction and returns it to myetherwallet as illustrated here:

image

The return value should be a signed, raw transaction. For example 0xf864808502540be4008252089429fe8914e76da5ce2d90de98a64d0055f199d06d808025a0aae01c955ba016574a64f3cf10dcd0f885d73e684dd252c05bccc016e4b66a6da01908951150436377b038f951ab055a5fca5d066950d649aead6e041020785662 for the simple case from the screenshot.

To fix this issue, I'd suggest that MetaMask starts supporting the Web3 RPC method eth.signTransaction as documented here (https://web3js.readthedocs.io/en/v1.2.11/web3-eth.html#signtransaction). When trying to call this method through Web3js with the current version of MetaMask, web3js returns with "Error: The method 'eth_signTransaction' does not exist / is not available.". This is probably also the error @jennypollack was referring to. (Edit: Sorry, I meant @iris112 )

As an important note, MetaMask should support the nonce property in this case and not ignore it! If an application is requesting a transaction to be signed without sending it to the network, it should be assumed that the application knows what it is doing and thus also is requesting the correct nonce. In fact, in case there are multiple pending "offline" transactions that the application plans to send to the network later, MetaMask cannot figure out what the correct nonce should be as these transactions are not known yet in the network.

luziusmeisser commented 4 years ago

Maybe some more details about my use case, just to provide some background information. I am working on a multisignature contract that allows to separate the signing and the paying of a transaction. So one user can sign it without using any gas and then another user can send the transaction to the multisignature contract and pay for it. Gas station network uses a similar concept to pay for user transactions. It allows to develop user-friendly dapps that can also be used by users that have no Ether. For security reasons, we do not want to resort to sign raw hashes, but use the much more transparent "sign transaction" method instead that allows wallets to tell the user what they are actually signing.

As a further sidenote: MetaMask should in such cases not only trust that the calling application set the nonce correctly, but not interfere with the gas limit and gas cost (if provided). In our use case, 0 are valid values for both the gas limit as well as the gas costs as those are paid for later in a separate transaction.

pcaversaccio commented 4 years ago

@kronrod take a look at the thread here. I just remember it since we had similar issues with Alethena back then and MetaMask won't change its mind I suppose.

luziusmeisser commented 4 years ago

@pcaversaccio thanks for the hint. It sounds like the devs behind MetaMask are unable to recognize this need. Fortunately, we will have our own wallet soon. :)

Gudahtt commented 3 years ago

Closing, as the original reported issue here didn't include enough detail to investigate, and the follow-up conversation seems to be about something entirely different.