Continuing discussion from EIPIP Meeting 88 · Issue #257 · ethereum-cat-herders/EIPIP · GitHub
Supposing that:
- ERC-20 allows users to send funds to addresses that don’t support ERC-20 tokens.
- ERC-223 allows users to send funds to addresses that don’t support ERC-223 tokens.
- “any standard that allows a user to make such a mistake […] is insecure”.
Then, exactly one of the following is true:
- Neither ERC-20 nor ERC-223 are labelled insecure.
- Both ERC-20 and ERC-223 are labelled insecure.
- EIP Editors have to subjectively determine if the enhancements of ERC-223 are sufficient to be “secure”.
@SamWilsn I just don’t get why you keep ignoring software security design principles that I provided earlier.
It is written here what can be considered “secure”:
https://docs.oracle.com/en/operating-systems/oracle-linux/6/security/ol_desprinsc_sec.html
Supposing that:
- Anything that implements (1) error handling, (2) abstraction of users from the internal logic of the software and other principles described in the “standard secure software design” articles is SECURE
- Anything that DOES NOT implement what is described in the “standard secure software design” articles is NOT SECURE
Then the following would be true:
- ether, ERC-223, EOS C++ tokens, ERC-721 NFTs are secure
- ERC-20, ERC-777, ERC-1363 are not secure
We are not talking about an opportunity to allow user mistake. We are talking about impossibility of handling user mistakes on the recipients side here.
The problem of sending to wrong address by mistake is not a problem of the token standard (ERC-20 or ERC-223) - it is a problem of Ethereum addresses.
For example EOS does not allow sending to “wrong addresses” because it has a built-in nameservice. This is a totally different problem. We don’t need to mix “the problem of insecure token standard design” and “the problem of how raw addresses are handled at protocol-level” together.
- ERC-223 allows users to send funds to addresses that don’t support ERC-223 tokens.
btw this is simply incorrect. The main point of ERC-223 is that it doesn’t allow users to send funds to addresses that are known to not support ERC-223 tokens.
If your contract is insecure, it doesn’t matter what guidelines or practices you followed to get there; it’s still insecure. On the flip side, even if you follow all these guidelines, they can’t protect you from a flawed economic assumption or similarly incorrect algorithm.
Besides that, they are subjective: different authorities will have different practices. Even if everyone agreed on the same guidelines, evaluating whether an EIP follows them is still subjective.
I disagree with your first premise.
My counterexample: I build a smart contract wallet with 2FA, that checks every action against ACLs, logs all errors, only runs the minimal number of services on each server, actively models threats and reacts accordingly, encrypts everything with the latest industry standard algorithms, sanitizes all inputs and outputs, and has a central owner key that can access any wallet.
This wallet meets or exceeds all the design practices from your first link, but is clearly insecure from a user’s point of view.
“But wait,” you might say, “having a second key violates the access control principle!”
That depends on your perspective. These guidelines are subjective. Even if I agreed with your premises, I couldn’t apply them to the EIP process.
As far as I am aware, there are at least two cases where you cannot feasibly detect if an address supports ERC-223 tokens.
First, if I pick an arbitrary address (say 0x0000000000000000000000000000000000000000). Can you prove that a private key is known (or even exists) for that address? If not, you can’t be sure that address will ever be able to release the tokens.
Secondly, counterfactual contracts exist, and are in active use. You can take some bytecode, a known deployer, and with CREATE2, predict the exact address where it’ll end up. Some smart contract wallets use this approach to defer paying fees until the user wants to withdraw funds. You can’t know ahead of time whether the contract deployed in this way will support ERC-223.
Your reference implementation uses extcodesize, which would allow tokens to be locked in both these cases.
(aside) there is a way to actually make sure the receiving address supports ERC-223, but it’s brittle and I wouldn’t recommend it: if there is code, use tokenReceived; if there is no code, require at least two signed messages from the address. I’ll leave the rationale as an exercise for future readers.
If some spec directly violates “common security practices” - it is 100% not secure (the case of ERC-20).
If the spec not violate “common security practices” then we can’t say that it’s insecure for sure unless someone discloses a security flaw there (true for most of other EIPs).
We can’t say that something is SECURE because it adheres to security practices, this is true. But we can say for sure that something is NOT SECURE if it does not adhere to these practices.
It becomes less subjective if you ask someone with deeper experience in security area or security auditing. I would strongly advocate that a dedicated security expert must participate in the EIP assessment.
Assuming that general commonsense is enough to develop secure software resulted in $200M being lost.
Ok, I agree that implementing what is described in “secure software design principles” does not guarantee that the implementation is secure.
However cruel violations of “secure software design principles” guarantee that the implementation is insecure.
I would rephrase it for the context of EIPs: If something adheres to “secure software design principles” then there is no need to label it. If something does not - then it must be labelled as potentially insecure because it violates rule XYZ.
Not a problem of token standard. This is a problem of Ethereum architecture and how addresses work on Ethereum. It is possible to develop a safer solution - see EOS “accounts” system but this has nothing to do with ERC-223.
ERC-223 prevents mistakes. Sometimes it is not possible to identify if something is a mistake or not. Then it does not prevent it.
ERC-20 does not prevent mistakes. Period.
Again, we had similar discussion with Nick Johnson 6 years ago.
What I call “possible loss of funds” resulted in a loss of $200M.
What you call “possible loss of funds” will never cause any problems because it is artificially constructed opportunity to intentionally exploit some edge cases of the underlying platform not even related to the token standard implementation.