Source: MetaCat
EIP-3074 co-authors here! Let me put this worry to rest for a second before things get even more out of hand.
First of all: I am not aware of any wallet that currently supports signing unprefixed data. This means that no wallet currently supports EIP-3074. No matter how many dashboards you browse or how many advanced features you turn on. It is not possible to sign EIP-3074 messages right now.
You sign messages for the "login" dapp using a completely different standard than EIP-3074, based on EIP-191. This will add the following data to your signed message: 0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> <data to sign This is why it is impossible to trick someone logged into your dapp into actually signing a valid Ethereum transaction. Transactions are prefixed with a single byte value: 0x01 - 2930 tx 0x02 - 1559 tx 0x03 - 4844 tx For more information, see: https://github.com/ethereum/execution-specs/tree/master/lists/signature-types
EIP-3074 plans to use the prefix 0x04. This will disambiguate it from all other types of signable data in Ethereum. Wallets must actively opt-in to allow users to sign these messages.
Depending on how your wallet integrates EIP-3074, it could make it easier for users to be exploited. To understand this, we need to make sure we understand how EIP-3074 signatures work.
The authentication message that builds the signature has the following fields. Importantly, it includes a caller address. This is the only address that AUTH considers the signature valid.
At a minimum, wallet software should make signing EIP-3074 messages a big deal, just like exporting your private key is a big deal.
Assuming wallets integrate 3074 securely, accounts can still be compromised. This is a fundamental property of batched transactions. It allows you to easily send multiple operations, just as it allows an attacker to trick you into sending a batch of assets to an address they control.
Wallet software must clearly display each operation you are signing. That way, it's easy to notice "I only intended to make one transaction, but this signature request made me make a dozen more transactions". If batching is done via blind signing, this cannot be detected.
Yes, EIP-3074 puts a lot of trust in the wallet. However, we already safely trust them with our private keys! There is no higher level of trust.
It is safe to integrate and use EIP-3074. If any wallet has questions about how to do this, please feel free to contact us. As the authors of EIP-3074, we are currently considering how we can best help with the next phase of the standard's development.
Over the past few years, we have spent a lot of time developing hypothetical scenarios about how it can be used and abused. We are excited that these ideas are starting to make it into production. But we also recognize that this is the hardest part.
To summarize the concerns about a single bad signature draining your Ethereum account balance after EIP-3074:
- Currently wallets do not support EIP-3074 type signatures, which follow a new format.
- The caller field in the EIP-3074 signature is very important. A bad caller could potentially steal your funds.
- Wallets need to ensure the caller address is trusted. This is similar to how wallets currently prevent arbitrary code execution.
- Batching transactions in EIP-3074 still opens up a world where malicious actors could trick you into signing a transaction that transfers assets. Wallets need to clearly display what happens when an EIP-3074 message is signed.
- Yes, we have a high level of trust in wallets, but users have entrusted them with their private keys, and that is the highest level of trust.
EIP-3074 and EIP-4337
EIP-3074 is a very good thing for Account Abstraction providers because it is very beneficial to our customers.
- ERC-4337 is the best way to introduce new users to the crypto space.
- EIP-3074 is the best way to introduce existing users to Smart Accounts.
Original link: https://twitter.com/lightclients/status/1778823652584120497
EIP-3074 will be launched in the next Ethereum hard fork.