fix typos (#1172)

Author: xiaobei0715

EIP_AUTHORS_MANUAL.md

@@ -6,7 +6,7 @@ This document outlines the process of specifying and testing EIPs for the Ethere
 | ------------------ | ----------- | ------- |
 | _Pre‑Draft_        | Prospective EIP author conceives of an idea for an improvement to Ethereum, and discusses with the community. | <ul><li>Vague Consensus on [Ethereum Magicians][0]</li></ul> |
 | **Draft**          | <p>EIP author writes a technical human-language document describing the improvement, initially in broad strokes and becoming more specific over time.</p><p>Concurrently, they develop a Python reference implementation to make the EIP executable and identify any immediate/obvious implementation issues. For example, the EIP may not be compatible with some detail of the current Ethereum Virtual Machine.</p><p>Finally for this stage, the author begins to write test schemes for the EIP. Having the reference implementation should help identify the various logical flows to test and thus feed into more robust testing. Once the test schemes are written, the reference implementation can then be used to fill the tests and generate the test vectors.</p> | <ul><li>Complete (but not final) document in [EIPs Repository][1]</li><li>Reference Implementation in [EELS][2]</li><li>Initial Tests in [EEST][3]</li></ul> |
-| **Review**         | <p>The broader Ethereum community discusses and provides input on the proposal.</p><p>Although the feedback from the community can be sought at all lifecycle stages, having a reference implementation and tests act as a good bridge between research and client implemtation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.</p> | <ul><li>Complete &amp; final document in the [EIPs Repository][1]</li><li>Comprehensive tests in [EEST][3]</li></ul>
+| **Review**         | <p>The broader Ethereum community discusses and provides input on the proposal.</p><p>Although the feedback from the community can be sought at all lifecycle stages, having a reference implementation and tests act as a good bridge between research and client implementation. It also helps core developers (who have limited time and resources) to understand the EIP better and provide more informed feedback.</p> | <ul><li>Complete &amp; final document in the [EIPs Repository][1]</li><li>Comprehensive tests in [EEST][3]</li></ul>
 | **Last&nbsp;Call** | Usually after being nominated for inclusion in a fork, the EIP author signals that the proposal is effectively done and begins the last period for comments/discussion. | <ul><li>Complete reference implementation in [EELS][2]</li><li>Complete tests in [EEST][3]</li><li>Immutable proposal in [EIPs Repository][1]</li></ul> |
 | **Final**          | The proposal is now immutable (cannot be changed) and exists for reference. | <ul><li>Mainnet client implementations</li></ul> |
 

lists/evm/proposed-opcodes.md

@@ -1,7 +1,7 @@
 All Proposed Opcodes
 --------------------
 
-All EIP propsoed opcodes that have not shipped. This includes all
+All EIP proposed opcodes that have not shipped. This includes all
 unshipped EIPs, even withdrawn and non-viable proposals.
 
 | EIP                                                                    | Opcode | Name               | Description                                                                  |

lists/signature-types/README.md

@@ -12,7 +12,7 @@ Reserved or Tentative.
 
 | Prefix byte | Specs or Purpose |
 |-------------|------------------|
-| 0x00  | Reserved: indicates legacy (untyped) trancactions |
+| 0x00  | Reserved: indicates legacy (untyped) transactions |
 | 0x01  | Reserved: [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) *(available in Berlin)* |
 | 0x02  | Reserved: [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) *(available in London)* |
 | 0x03  | Reserved: [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) *(available in Cancun)* |
@@ -50,7 +50,7 @@ since a valid RLP-encoded transaction could not begin with it (prior to
 [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718)) and represents the
 Bitcoin varint length of the string `"Ethereum signed Message:\n"`.
 
-It was carried over from the technique Bitcon used to sign personal messages
+It was carried over from the technique Bitcoin used to sign personal messages
 (which uses `"\18Bitcoin signed message:\n"`) but was extended with
 [EIP-191](https://eips.ethereum.org/EIPS/eip-191), which effectively
 retconned signed personal messages into a scheme that is extensible,

network-upgrades/mainnet-upgrades/muir-glacier.md

@@ -20,7 +20,7 @@ Ethereum achieves a consistent block time due to its' difficulty retargeting alg
 
 The primary problem with the Ice Age is that it is included in the complex mechanism that targets block times, which is an entirely separate in purpose. What is worse is due to being intwined with that algorithm, it is very difficult to simulate or predict its effect on the network. To predict the impact of the ice age, you must both make assumptions about the difficulty of main-net in the future, and predict the effect of changes in difficulty to the impact on the ice age and thus block-times.
 
-This fork will push back the Iceage as far as far as is reasonable and will give us time to update the Iceage to no longer have these design problems. There are two solutions to consider within that time frame.
+This fork will push back the Iceage as far as is reasonable and will give us time to update the Iceage to no longer have these design problems. There are two solutions to consider within that time frame.
 
  - Update the mechanism so that behavior is predictable.
  - Remove the Iceage entirely