Parity panics on networkID: 0?

[shisoft]

I'm running:

• Which Parity version?: Parity/v1.9.5-stable-ff821da-20180321/x86_64-linux-gnu/rustc1.24.1
• How installed?: deb in docker
• Are you fully synchronized?: yes
• Which network are you connected to?: Private AuthorityRound engine
• Did you try to restart the node?: yes

I am getting this panic on an account defined in chain spec. The account was created in a placeholder chain spec through command line and then copy to the actual authority chain key folder before started.

This happened every time I tried to transfer balance to another account and parity wallet asked me to sign the transaction.

When I tring to repeat this, it occurs all the time.

Error in question:
panicked at 'Transaction was signed by AccountsProvider; it never produces invalid signatures; qed: Ethkey(InvalidSignature)'

[Tbaut]

The steps to reproduce your issue aren't clear to me. Could you please describe your setup and provide your chain spec ?

[debris]

It was already reported in #7302

[shisoft]

My chain spec is.

The account 0x25dc526a6cd43059979101867d0f250344c8ffb6 is the one cause this panic.

{
  "name": "parity-net",
  "engine": {
    "authorityRound": {
      "params": {
        "stepDuration": "5",
        "validators": {
          "list": [
            "0x4bc39aeb7fa35cae4243279b0903c7c057b34c07",
            "0x16fb22f3c2a25d687ca4cc1b94d79ad74570da1a",
            "0x171bc702052c4a925f06af3aca19158ac5b34261"
          ]
        }
      }
    }
  },
  "params": {
    "gasLimitBoundDivisor": 1024,
    "maximumExtraDataSize": 32,
    "minGasLimit": 5000,
    "networkID": 0
  },
  "genesis": {
    "seal": {
      "authorityRound": {
        "step": 0,
        "signature": "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
      }
    },
    "difficulty": 200000000,
    "gasLimit": 2100000
  },
  "accounts": {
    "0x25dc526a6cd43059979101867d0f250344c8ffb6": {
      "balance": "9223372036854775807"
    },
    "0x0000000000000000000000000000000000000001": {
      "balance": "1",
      "builtin": {
        "name": "ecrecover",
        "pricing": {
          "linear": {
            "base": 3000,
            "word": 0
          }
        }
      }
    },
    "0x0000000000000000000000000000000000000002": {
      "balance": "1",
      "builtin": {
        "name": "sha256",
        "pricing": {
          "linear": {
            "base": 60,
            "word": 12
          }
        }
      }
    },
    "0x0000000000000000000000000000000000000003": {
      "balance": "1",
      "builtin": {
        "name": "ripemd160",
        "pricing": {
          "linear": {
            "base": 600,
            "word": 120
          }
        }
      }
    },
    "0x0000000000000000000000000000000000000004": {
      "balance": "1",
      "builtin": {
        "name": "identity",
        "pricing": {
          "linear": {
            "base": 15,
            "word": 3
          }
        }
      }
    }
  }
}

The account private key files were created under another chain spec with different name and then copied to this chain.

[Yonom]

Hey,

"networkID": 0

Pick another number! Parity doesn't like networkID 0

[5chdn]

Pull requests welcome :)

[debris]

Hey,

"networkID": 0

Pick another number! Parity doesn't like networkID 0

I'm not sure I understand. @folsen how networkID is related to the reported issue?

[folsen]

@debris me either :S I just went by the last report, it may be inaccurate, that's why I also put it in needs investigation

[seunlanlege]

networkID is also used as a chain_id for chain replay protection, a chain_id of 0 causes undefined behaviour in the signing process.

The fix here would be to prevent a 0 value for networkID so in the future people don't run into this issue.