doc: add security to appearances spec

Author: perama-v

src/eth/addresses.md

@@ -29,7 +29,7 @@ The identification of an appearance solves a discovery problem. Once an importan
 for a particular address have been found, an analysis of what the appearance means can be performed,
 although this is beyond the scope of this specification.
 
-## Specification
+## Terminology
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
 
@@ -284,4 +284,63 @@ It can be seen in the example below (a subset of the response from the above cal
     "type": "CALL"
     }
 }
-```
+```
+
+## Security Considerations
+
+The EVM allows for use of data that has the same structure as a 20 byte address.
+The algorithm used to find address appearances ideally minimises missing appearances
+(false negatives) and so may include false positives.
+
+### False positives: Appearances returned for addresses that do not exist
+
+Some non-address data with a particular encoding may be used and be misclassified
+as an address. For example, calldata for a specific application that is not
+encoding for an address.
+
+False positives can lead to a larger response size, and wasted effort if performing
+semantic analysis of transactions for addresses found.
+
+### False negatives: Vanity address
+
+An address may be found with more zeros than the specification allows. This
+process involves generating private keys and checking the associated address.
+
+The presence of such a "vanity address" will not be detected by algorithms
+conforming to this specification. This design tradeoff allows fewer false positives.
+
+### False negatives: Address composition
+
+A contract may manipulate separate bytes to construct an address and then use this
+for an opcode that does not get detected by the algorithm, such as BALANCE.
+
+This will be missed by the algorithm, which constitutes an appearance of the address
+(its balance was checked) that will be absent in semantic analysis. This impact is
+limited a the subset of opcodes (BALANCE, EXTCODESIZE, ...) and any analysis should take
+this into account.
+
+### Multiple appearances
+
+An address may appear multiple times within a block, as any combination of intra-transaction
+and extra-transaction appearances. The method response includes transaction indices
+for all intra-transaction indices. It is the responsibility of the caller to check
+if the block also containes extra-transaction appearances when a transaction index is returned.
+
+For example, a user may receive a withdrawal and perform a transaction in the same block.
+
+### Precompiles
+
+Existing precompiles are located at addresses `0x01` to `0x09`. They do
+not meet definitional criteria and SHOULD NOT be included.
+
+Future precompiles may be deployed at addresses that meet criteria however, SHOULD NOT be included
+as addresses.
+
+### Node size
+
+The `eth_getAddressesInBlock` endpoint is designed to allow the node to compute the result
+on-the-fly and does not imply an increase in the database requirement for the node.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).