fip-0039: update chain ids (#690)

* fip-0039: update chain ids

ref: ethereum-lists/chains#1567

* fix fip number in references

* remove chainid considerations from fip-0039

FIPS/fip-0039.md

@@ -21,11 +21,12 @@ Currently, transactions signed for testnets are also valid on mainnet and could
 ## Specification
 ### Chain Identifiers
 The following chain IDs **MUST** be defined for the Filecoin networks.
-- Filecoin: `CHAIN_ID := 1` (TBD)
-- Interopnet: `CHAIN_ID := 10` (TBD)
-- Butterlfynet: `CHAIN_ID := 20` (TBD)
-- Calibnet: `CHAIN_ID := 30` (TBD)
-- Devnet: `CHAIN_ID := 4269` (TBD)
+- Filecoin: `CHAIN_ID := 314`
+- Hyperspace: `CHAIN_ID := 3141`
+- Wallaby: `CHAIN_ID := 31415`
+- Butterlfynet: `CHAIN_ID := 3141592`
+- Calibnet: `CHAIN_ID := 314159`
+- Devnet: `CHAIN_ID := 31415926`
 
 ### Unsigned Messages
 The unsigned message **SHOULD** be appended by an additional field `chain_id`. Legacy messages remain valid but **SHOULD** be deprecated.
@@ -47,7 +48,7 @@ class UnsignedMessageLegacy:
   gas_premium: int = 0
 
 @dataclass
-class UnsignedMessageFip9999:
+class UnsignedMessageFip0039:
   version: int = 0
   from: int = 0
   to: int = 0
@@ -73,12 +74,12 @@ A signature is a serialization of the fields `r | s | v`. Note that `v` value is
 ## Design Rationale
 Both Bitcoin and Ethereum use `v` instead of a recovery ID. Bitcoin uses a value of `v` in `{27,28,29,30,31,32,33,34}` to allow recovering public keys on all four possible points on the elliptic curve for both uncompressed and compressed public keys. This does not apply to Filecoin, however, note that the `+ 35` offset in the `v` specifically allows to distinguish between Bitcoin and Filecoin signatures.
 
-Ethereum uses a similar replay protection in [EIP-155](https://eips.ethereum.org/EIPS/eip-155). It **COULD** be considered to choose a set of `CHAIN_ID`s that do not conflict with EVM chains. (TBD)
+Ethereum uses a similar replay protection in [EIP-155](https://eips.ethereum.org/EIPS/eip-155).
 
 The `v` value will be encoded at the end of the signature to allow for the easy determination of `v` values for `v > ff`.
 
 ## Backwards Compatibility
-FIP9999 Messages and Signatures are not backward compatible and there will always be the need to maintain both, legacy transactions and FIP9999 transactions.
+FIP0039 Messages and Signatures are not backward compatible and there will always be the need to maintain both, legacy transactions and FIP0039 transactions.
 
 The main breaking changes are:
 * one additional field of `chain_id` in the unsigned message