Do we need replay protection? FIP0039

[q9f]

This is the discussion for 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.

Full spec: https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0039.md

Ref: #300 #690

Context: ChainSafe/forest#1419

See also: ethereum-lists/chains#1567

[jleni]

I brought up this problem a few times in the past (a couple of years ago).. before moving to mainnet.

https://filecoinproject.slack.com/archives/CP50PPW2X/p1579091836331600

I think it is definitely something that should be included.. but at the moment, it can result in a lot of changes so if this goes forward the effect in the ecosystem (wallets, hw wallets, explorers, etc) should be analysed in detail.

[q9f]

Hi Juan! Thank you for your comment. It's the same issue as we had with the ETH/ETC hardfork and EIP-155. It would have been nice if we had this right from genesis, I agree.

[Stebalien]

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.

Users should not be re-using keys between mainnet and testnet for security reasons. Personally, I'd be against adding any features that might encourage that.

[anorth]

It's a valid "should", but I don't think it's very realistic, especially as web3 gains ever wider adoption (including developer adoption and hence testnet use).

[jennijuju]

I think only networks that are listed here should be considered to define a chain ID to.

[dd45e640b42e6da7da96faee3996ef7c]

if there are fil-chain IDs then we should define a mechanism where people can either apply for, or just grab, them in a central/official public place. ETH not doing that lead to some unfunny consequences

[q9f]

who is the central official in a decentralized network though?

[q9f]

I updated the chain IDs from the FEVM, ref: ethereum-lists/chains#1567

[Kubuxu]

Consideration of BLS signing scheme is missing from the FIP draft.

[jennijuju]

Chain IDs are introduced with FEVM https://github.com/filecoin-project/FIPs/blob/956acf61fd911e4eb00b3be0dcc11f2c3cb106b6/FIPS/fip-0054.md#eip-155-chain-ids-of-filecoin-networks. and the client implementation like lotus, we include the chain id in the eth tx with the required signature https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0055.md#delegated-signature-type. Is there anything else needed for this?

[Stebalien]

Not quite. Messages sent from EthAccounts can't be replayed, but messages sent from "native" accounts still can.

We could add the chain ID to native messages (now that we have one) but that would require one of two things. Either:

1. We'd change the message format to include the chain ID (an annoyingly pervasive change).
2. We'd "stuff" the chain ID into the signed data without actually including it in the message itself.

Basically, this is totally doable but not "almost done".

[jennijuju]

ah-ha thank you for the correction and clarification

[Kubuxu]

@anorth @Stebalien flagging that this never got into production and will become an issue if/when we introduce user-programmable FVM or non-FEVM-based IPC/L2s.