ERC-5564 Remove reference implementation

ERCS/erc-5564.md

@@ -107,10 +107,10 @@ contract IERC5564Announcer {
   /// @dev Emitted when sending something to a stealth address.
   /// @dev See the `announce` method for documentation on the parameters.
   event Announcement (
-    uint256 indexed schemeId, 
-    address indexed stealthAddress, 
-    address indexed caller, 
-    bytes ephemeralPubKey, 
+    uint256 indexed schemeId,
+    address indexed stealthAddress,
+    address indexed caller,
+    bytes ephemeralPubKey,
     bytes metadata
   );
 
@@ -119,7 +119,7 @@ contract IERC5564Announcer {
   /// @param stealthAddress The computed stealth address for the recipient.
   /// @param ephemeralPubKey Ephemeral public key used by the sender.
   /// @param metadata An arbitrary field MUST include the view tag in the first byte.
-  /// Besides the view tag, the metadata can be used by the senders however they like, 
+  /// Besides the view tag, the metadata can be used by the senders however they like,
   /// but the below guidelines are recommended:
   /// The first byte of the metadata MUST be the view tag.
   /// - When sending/interacting with the native token of the blockchain (cf. ETH), the metadata SHOULD be structured as follows:
@@ -137,9 +137,9 @@ contract IERC5564Announcer {
   ///   - Bytes 26-57 are the amount of tokens being sent/interacted with for fungible tokens, or
   ///     the token ID for non-fungible tokens.
   function announce (
-    uint256 schemeId, 
-    address stealthAddress, 
-    bytes memory ephemeralPubKey, 
+    uint256 schemeId,
+    address stealthAddress,
+    bytes memory ephemeralPubKey,
     bytes memory metadata
   )
     external
@@ -157,7 +157,7 @@ Thus, a stealth meta-address on Ethereum has the following format:
 
 ```
 st:eth:0x<spendingKey><viewingKey>
-``` 
+```
 
 Stealth meta-addresses may be managed by the user and/or registered within a publicly available `Registry` contract, as delineated in [ERC-6538](./eip-6538). This provides users with a centralized location for identifying stealth meta-addresses associated with other individuals while simultaneously enabling recipients to express their openness to engage via stealth addresses.
 
@@ -199,14 +199,14 @@ The following reference is divided into three sections:
   - Multiply the hashed shared secret with the generator point $S_h = s_h \cdot G$.
   - The recipient's stealth public key is computed as $P_{stealth} = P_{spend} + S_h$.
   - The recipient's stealth address $a_{stealth}$ is computed as $\textrm{pubkeyToAddress}(P_{stealth})$.
-  - The function returns the stealth address $a_{stealth}$, the ephemeral public key $P_{ephemeral}$ and the view tag $v$. 
+  - The function returns the stealth address $a_{stealth}$, the ephemeral public key $P_{ephemeral}$ and the view tag $v$.
 
 
 #### Parsing - Locate one's own stealth address(es):
 
 - User has access to the viewing private key $p_{view}$ and the spending public key $P_{spend}$.
 
-- User has access to a set of `Announcement` events and applies the `checkStealthAddress` function to each of them. 
+- User has access to a set of `Announcement` events and applies the `checkStealthAddress` function to each of them.
 
 - The  `checkStealthAddress` function performs the following computations:
   - Shared secret $s$ is computed by multiplying the viewing private key with the ephemeral public key of the announcement $s = p_{view}$ * $P_{ephemeral}$.
@@ -221,7 +221,7 @@ The following reference is divided into three sections:
 
 - User has access to the viewing private key $p_{view}$ and spending private key $p_{spend}$.
 
-- User has access to a set of `Announcement` events for which the `checkStealthAddress` function returns `true`. 
+- User has access to a set of `Announcement` events for which the `checkStealthAddress` function returns `true`.
 
 - The  `computeStealthKey` function performs the following computations:
   - Shared secret $s$ is computed by multiplying the viewing private key with the ephemeral public key of the announcement $s = p_{view}$ * $P_{ephemeral}$.
@@ -258,15 +258,11 @@ The recipient's address and the `viewTag` MUST be included in the announcement e
 
 This ERC is fully backward compatible.
 
-## Reference Implementation
-
-You can find an implementation of this standard in TBD.
-
 ## Security Considerations
 
 ### DoS Countermeasures
 
-There are potential denial of service (DoS) attack vectors that are not mitigated by network transaction fees. Stealth transfer senders cause an externality for recipients, as parsing announcement events consumes computational resources that are not compensated with gas. Therefore, spamming announcement events *can* be a detriment to the user experience, as it *can* lead to longer parsing times. 
+There are potential denial of service (DoS) attack vectors that are not mitigated by network transaction fees. Stealth transfer senders cause an externality for recipients, as parsing announcement events consumes computational resources that are not compensated with gas. Therefore, spamming announcement events *can* be a detriment to the user experience, as it *can* lead to longer parsing times.
 We consider the incentives to carry out such an attack to be low because **no monetary benefit can be obtained**
 However, to tackle potential spam, parsing providers may adopt their own anti-DoS attack methods. These may include ignoring the spamming users when serving announcements to users or, less harsh, de-prioritizing them when ordering the announcements. The indexed `caller` keyword may help parsing providers to effectively filter known spammers.