Skip to content

Latest commit

 

History

History
111 lines (86 loc) · 4.34 KB

fip-0039.md

File metadata and controls

111 lines (86 loc) · 4.34 KB
Raw
fip title author discussions-to status type category created
0039
Filecoin Message Replay Protection
Afri Schoedon (@q9f)
Draft
Technical
Core
2022-02-16

FIP-0039: Filecoin Message Replay Protection

Simple Summary

Defines Filecoin chain identifiers and adds them to unsigned messages and signatures to prevent transactions to be replayed across different Filecoin networks.

Abstract

The proposal adds a field to unsigned messages indicating which chain a transaction is intended for. In addition, signatures encode the chain they are targeted for to prevent clients from accepting signed messages to be replayed across all Filecoin networks.

Change Motivation

Currently, transactions signed for testnets are also valid on mainnet and could be replayed. The motivation of this specification is to prevent that by specifically introducing network identifiers for all Filecoin main and test networks and adding them explicitly to the unsigned messages and signatures.

Specification

Chain Identifiers

The following chain IDs MUST be defined for the Filecoin networks.

  • 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.

from dataclasses import dataclass

@dataclass
class UnsignedMessageLegacy:
  version: int = 0
  from: int = 0
  to: int = 0
  sequence: int = 0
  value: int = 0
  method_num: int = 0
  params: bytes()
  gas_limit: int = 0
  gas_fee_cap: int = 0
  gas_premium: int = 0

@dataclass
class UnsignedMessageFip0039:
  version: int = 0
  from: int = 0
  to: int = 0
  sequence: int = 0
  value: int = 0
  method_num: int = 0
  params: bytes()
  gas_limit: int = 0
  gas_fee_cap: int = 0
  gas_premium: int = 0
  chain_id: int = 0

Signatures

The signature of a message SHOULD NOT contain a recovery ID (or "y-parity"); instead it MUST contain a value v that encodes both the chain_id and the recovery_id.

v = recovery_id + CHAIN_ID * 2 + 35

A signature is a serialization of the fields r | s | v. Note that v value is appended not prepended.

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.

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

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
  • using v instead of recovery_id in the signatures
  • moving the v value to the end of the signature.

Test Cases

Test Cases can be provided after further discussion of the proposal.

Security Considerations

This proposal supposedly enhances chain and user security by preventing replay protection across different Filecoin networks.

Notably, EIP-155 has been in use by Ethereum for more than five years and has proven robust.

Incentive Considerations

This FIP does not affect incentives in itself and is of pure technological nature without any impact on economic factors.

Product Considerations

Applications and products should be encouraged to adapt this FIP as it enhances end-user security; at the same time legacy transactions should be discouraged.

However, since legacy transactions are not invalid for the time being, the impact on applications is fairly low.

Implementation

An implementation can be provided after further discussion of the proposal.

Copyright

Copyright and related rights waived via CC0.