Hi, I experienced a similar problem today while deploying to xDai (chainId = 100).

$ truffle migrate --reset --network xdai

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



Starting migrations...
======================
> Network name:    'xdai'
> Network id:      100
> Block gas limit: 12500000 (0xbebc20)


01_initial_migration.js
=======================

   Replacing 'Migrations'
   ----------------------

Error:  *** Deployment Failed ***

"Migrations" -- Invalid chain id..

    at /home/christoph/.nvm/versions/node/v10.15.3/lib/node_modules/truffle/build/webpack:/packages/deployer/src/deployment.js:365:1
    at process._tickCallback (internal/process/next_tick.js:68:7)
Truffle v5.3.1 (core: 5.3.1)
Node v10.15.3

Steps to reproduce:

• clone https://github.com/etherisc/flightdelay-contracts/tree/82e7eec844ecdebcce2eda0b9ba239c8fe0a7db9
• npm i
• npm i @truffle/hdwallet-provider@latest
• (edit truffle-config.js with your HDWallet Parameters)
• truffle migrate --reset --network xdai

It works with @1.2.1, but still gives a lot of timeout errors which cannot be fixed by setting networkCheckTimeout or pollingInterval.

truffle-config parameters used:

HTTP_PROVIDER="https://xdai-rpc.etherisc.com"
TRUFFLE_HOST="wss://xdai-rpc.etherisc.com"
TRUFFLE_PORT="443"
TRUFFLE_NETWORK_ID=100
TRUFFLE_WEBSOCKETS="true"

xdai-rpc.etherisc.com is an openethereum-3.0.1 node behind an nginx reverse proxy.

I have a similar problem when deploying to BSC testnet.

Error:  *** Deployment Failed ***
"Migrations" -- invalid sender.

#4010

To fix this issue, you need to pass a chainId parameter when creating the HDWalletProvider:

provider = new HDWalletProvider({
  mnemonic: mnemonicPhrase,
  providerOrUrl: "http://localhost:8545",
  chainId: 42
});

I just had this issue and spent a lot of time trying to figure out why it happened, until I found a question on StackOverflow with the same error and the author mentioned a named parameter.

To fix this issue, you need to pass a chainId parameter when creating the HDWalletProvider:

provider = new HDWalletProvider({
  mnemonic: mnemonicPhrase,
  providerOrUrl: "http://localhost:8545",
  chainId: 42
});

I just had this issue and spent a lot of time trying to figure out why it happened, until I found a question on StackOverflow with the same error and the author mentioned a named parameter.

wow!!!

Thanks everyone for providing your experience with this issue!

A recent geth update has started defaulting to requiring EIP-155 signed transactions, which HDWalletProvider doesn't automatically do unless a chainId option is passed in, and the chainId is the ID of a "known network" (ethereum testnets and mainnet, currently).

We need to do a couple of things here:

• error better, so it is clear what is failing and why
• improve HDWalletProvider so that it automatically fetches the chain ID from the network and signs the transaction with an EIP-155 signature.

Minimal repro here: https://github.com/gakonst/truffle-bug-repro.

The problem is that when using the chainId: 1337(e.g. with geth --dev), I get: Error: Chain with ID 1337 not supported, which comes from ethereumjs-vm/common

The chainId seems to get set here.

Plan for fixing this issue:

• Make hdwallet-provider fetch the chainId upfront (using a pattern like this to assign a Promise in the constructor). Then await that promise inside provider.send.
• If chainId is not available on the chain; it means we're pre-spurious dragon
• Allow specifying chainId to skip this behavior
• Add a chainSettings property to the constructor args (as a more verbose form of chainId). chainSettings would be type { chainId?: number | string; networkId?: number | string; hardfork?: string }. Each of these properties is optional, with the following implications:
  • chainId not being specified means we fetch it
  • hardfork not being specified means we default to some post-"spurious dragon" fork (maybe we default to "instanbul"?)
  • networkId not being specified likely can just be ignored, since ethereumjs-common doesn't appear to use it. If it is necessary, we can treat it the same as chainId and fetch when missing.
• Do we need a way (separately from hardfork) to allow non-EIP155 transactions? A flag in chainSettings called disableReplayProtection?

Other thoughts:

• We want to eliminate the positional arguments form for hdwallet's constructor - this form is already deprecated, do we want to remove this form now? Seems like "not yet; we should plan for this separately"