Update EIP-2242: Removed dead Ethereum RLP link

EIPS/eip-2242.md

@@ -1,4 +1,4 @@
 ---
 eip: 2242
 title: Transaction Postdata
 author: John Adler (@adlerjohn)
@@ -8,23 +8,23 @@
 category: Core
 created: 2019-08-16
 ---
 
 ## Simple Summary
 An additional, optional transaction field is added for "postdata," data that is posted on-chain but that cannot be read from the EVM.
 
 ## Abstract
 A paradigm shift in how blockchains are used has been seen recently in Eth 2.0, with the rise of [_Execution Environments_](https://notes.ethereum.org/w1Pn2iMmSTqCmVUTGV4T5A?view) (EEs), and [_stateless clients_](https://ethresear.ch/t/the-stateless-client-concept/172). This shift involves blockchains serving as a secure data availability and arbitration layer, _i.e._, they provide a globally-accepted source of available data, and process fraud/validity and data availability proofs. This same paradigm can be applied on Eth 1.x, replacing EEs with [trust-minimized side chains](https://ethresear.ch/t/building-scalable-decentralized-payment-systems-request-for-feedback/5312).
 
 ## Motivation
 While [EIP-2028](./eip-2028.md) provides a reduction in gas cost of calldata, and is a step in the right direction of encouraging use of history rather than state, the EVM does not actually need to see all data that is posted on-chain. Following the principle of "don't pay for what you don't use," a distinct way of posting data on-chain, but without actually being usable within the EVM, is needed.
 
 For [trust-minimized side chains with fraud proofs](https://ethresear.ch/t/minimal-viable-merged-consensus/5617), we simply need to ensure that the side chain block proposer has attested that _some_ data is available. Authentication can be performed as part of a fraud proof should that data end up invalid. Note that [trust-minimized side chains with validity proofs](https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477) can't make use of the changes proposed in this EIP, as they required immediate authentication of the posted data. This will be [the topic of a future EIP](https://ethresear.ch/t/multi-threaded-data-availability-on-eth-1/5899).
 
 ## Specification
 We propose a consensus modification, beginning at `FORK_BLKNUM`:
 
 An additional optional field, `postdata`, is added to transactions. Serialized transactions now have the format:
 ```
 "from": bytes20,
 "to": bytes20,
 "startGas": uint256,
@@ -33,24 +33,24 @@
 "data": bytes,
 "nonce": uint256,
 ["postdata": bytes],
 ```
-with witnesses signing over the [RLP encoding](https://github.com/ethereum/wiki/wiki/RLP) of the above. `postdata` is data that is posted on-chain, for later historical retrieval by layer-2 systems.
+with witnesses signing over the RLP encoding of the above. `postdata` is data that is posted on-chain, for later historical retrieval by layer-2 systems.
 
 `postdata` is an RLP-encoded twople `(version: uint64, data: bytes)`.
 1. `version` is `0`.
 1. `data` is an RLP-encoded list of binary data. This EIP does not interpret the data in any way, simply considering it as a binary blob, though future EIPs may introduce different interpretation schemes for different values of `version`.
 
 The gas cost of the posted data is `1 gas per byte`. This cost is deducted from the `startGas`; if the remaining gas is non-positive the transaction immediately reverts with an out of gas exception.
 
 ## Rationale
 The changes proposed are as minimal and non-disruptive to the existing EVM and transaction format as possible while also supporting possible [future extensions](https://ethresear.ch/t/multi-threaded-data-availability-on-eth-1/5899) through a version code.
 
 ## Backwards Compatibility
 The new transaction format is backwards compatible, as the new `postdata` field is optionally appended to existing transactions.
 
 The proposed changes are not forwards-compatible, and will require a hard fork.
 
 ## Test Cases
 TODO
 
 ## Implementation