Update ERC-5564: Fix broken links

Merged by EIP-Bot.

ERCS/erc-5564.md

@@ -12,7 +12,7 @@ created: 2022-08-13
 
 ## Abstract
 
-This specification establishes a standardized method for interacting with stealth addresses, which allow senders of transactions or transfers to non-interactively generate private accounts exclusively accessible by their recipients. Moreover, this specification enables developers to create stealth address protocols based on the foundational implementation outlined in this EIP, utilizing a singleton contract to emit the necessary information for recipients. In addition to the base implementation, this ERC also outlines the first implementation of a cryptographic scheme, specifically the SECP256k1 curve.
+This specification establishes a standardized method for interacting with stealth addresses, which allow senders of transactions or transfers to non-interactively generate private accounts exclusively accessible by their recipients. Moreover, this specification enables developers to create stealth address protocols based on the foundational implementation outlined in this ERC, utilizing a singleton contract to emit the necessary information for recipients. In addition to the base implementation, this ERC also outlines the first implementation of a cryptographic scheme, specifically the SECP256k1 curve.
 
 
 ## Motivation
@@ -72,22 +72,20 @@ A recipient MUST be able to compute the private key for a stealth address by cal
 /// @notice Computes the stealth private key for a stealth address.
 /// @param stealthAddress The expected stealth address.
 /// @param ephemeralPubKey The ephemeral public key used to generate the stealth address.
-/// @param viewingKey The recipient's viewing private key.
 /// @param spendingKey The recipient's spending private key.
 /// @return stealthKey The stealth private key corresponding to the stealth address.
 /// @dev The stealth address input is not strictly necessary, but it is included so the method
 /// can validate that the stealth private key was generated correctly.
 function computeStealthKey(
   address stealthAddress,
   bytes memory ephemeralPubKey,
-  bytes memory viewingKey,
   bytes memory spendingKey
 ) external view returns (bytes memory);
 ```
 
 The implementation of these methods is scheme-specific. The specification of a new stealth address scheme MUST specify the implementation for each of these methods. Additionally, although these function interfaces are specified in Solidity, they do not necessarily ever need to be implemented in Solidity, but any library or SDK conforming to this specification MUST implement these methods with compatible function interfaces.
 
-A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the EIP that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. Furthermore, the schemeId MUST be added to [this overview](../assets/eip-5564/scheme_ids.md). These extensions MUST specify:
+A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the ERC that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. Furthermore, the schemeId MUST be added to [this overview](../assets/erc-5564/scheme_ids.md). These extensions MUST specify:
 
 - The integer identifier for the scheme.
 
@@ -152,22 +150,22 @@ contract IERC5564Announcer {
 
 ### Stealth meta-address format
 
-The new address format for the stealth meta-address is based on [ERC-3770](./eip-3770.md) and extends it by adding a `st:` (*stealth*) prefix.
+The new address format for the stealth meta-address extends the chain specific address format by adding a `st:` (*stealth*) prefix.
 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.
+Stealth meta-addresses may be managed by the user and/or registered within a publicly available `Registry` contract, as delineated in [ERC-6538](./erc-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.
 
 *Notably, the address format is used only to differentiate stealth addresses from standard addresses, as the prefix is removed before performing any computations on the stealth meta-address.*
 
 ---
 
 ### Initial Implementation of SECP256k1 with View Tags
 
-This EIP provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Announcer` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/eip-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
+This ERC provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Announcer` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/erc-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
 
 The following reference is divided into three sections:
 
@@ -246,7 +244,7 @@ The view tags approach is introduced to reduce the parsing time by around 6x. Us
 
 ## Rationale
 
-This EIP emerged from the need for privacy-preserving ways to transfer ownership without disclosing any information about the recipients' identities. Token ownership can expose sensitive personal information. While individuals may wish to donate to a specific organization or country, they might prefer not to disclose a link between themselves and the recipient simultaneously. Standardizing stealth address generation represents a significant step towards unlinkable interactions, since such privacy-enhancing solutions require standards to achieve widespread adoption. Consequently, it is crucial to focus on developing generalizable approaches for implementing related solutions.
+This ERC emerged from the need for privacy-preserving ways to transfer ownership without disclosing any information about the recipients' identities. Token ownership can expose sensitive personal information. While individuals may wish to donate to a specific organization or country, they might prefer not to disclose a link between themselves and the recipient simultaneously. Standardizing stealth address generation represents a significant step towards unlinkable interactions, since such privacy-enhancing solutions require standards to achieve widespread adoption. Consequently, it is crucial to focus on developing generalizable approaches for implementing related solutions.
 
 The stealth address specification standardizes a protocol for generating and locating stealth addresses, facilitating the transfer of assets without requiring prior interaction with the recipient. This enables recipients to verify the receipt of a transfer without the need to interact with the blockchain and query account balances. Importantly, stealth addresses enable token transfer recipients to verify receipt while maintaining their privacy, as only the recipient can recognize themselves as the recipient of the transfer.
 
@@ -256,7 +254,7 @@ The recipient's address and the `viewTag` MUST be included in the announcement e
 
 ## Backwards Compatibility
 
-This EIP is fully backward compatible.
+This ERC is fully backward compatible.
 
 ## Reference Implementation
 
@@ -270,7 +268,7 @@ There are potential denial of service (DoS) attack vectors that are not mitigate
 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.
 
-Furthermore, parsing providers have a few options to counter spam, such as introducing staking mechanisms or requiring senders to pay a `toll` before including their `Announcement`. Moreover, a Staking mechanism may allow users to stake an unslashable amount of ETH (similarly to [ERC-4337](./eip-4337)), to help mitigate potential spam through *sybil attacks* and enable parsing providers filtering spam more effectively.
+Furthermore, parsing providers have a few options to counter spam, such as introducing staking mechanisms or requiring senders to pay a `toll` before including their `Announcement`. Moreover, a Staking mechanism may allow users to stake an unslashable amount of ETH (similarly to [ERC-4337](./erc-4337)), to help mitigate potential spam through *sybil attacks* and enable parsing providers filtering spam more effectively.
 Introducing a `toll`, paid by sending users, would simply put a cost on each stealth address transaction, making spamming economically unattractive.
 
 ### Recipients' transaction costs
@@ -282,4 +280,3 @@ Thus, the sender may attach a small amount of ETH to each stealth address transa
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).
-