Vulnerability: RocketDaoNodeTrustedActions - Incomplete implementation of member challenge process
Severity: high

Description:
Any registered (even untrusted) node can challenge a trusted DAO node to respond. The challenge is initiated by calling `actionChallengeMake`. Trusted nodes can challenge for free, other nodes have to provide `members.challenge.cost` as a tribute to the Ethereum gods. The challenged node must call `actionChallengeDecide` before `challengeStartBlock + members.challenge.window` blocks are over (default approx 7 days). However, the Golang codebase does not actively monitor for the `ActionChallengeMade` event, nor does the node - regularly - check if it is being challenged. Means to respond to the challenge (calling `actionChallengeDecide` to stop the challenge) are not implemented.\\nNodes do not seem to monitor `ActionChallengeMade` events so that they could react to challenges\\nNodes do not implement `actionChallengeDecide` and, therefore, cannot successfully stop a challenge\\nFunds/Tribute sent along with the challenge will be locked forever in the `RocketDAONodeTrustedActions` contract. There's no means to recover the funds.\\nIt is questionable whether the incentives are aligned well enough for anyone to challenge stale nodes. The default of `1 eth` compared to the risk of the “malicious” or “stale” node exiting themselves is quite high. The challenger is not incentivized to challenge someone other than for taking over the DAO. If the tribute is too low, this might incentivize users to grief trusted nodes and force them to close a challenge.\\nRequiring that the challenge initiator is a different registered node than the challenge finalized is a weak protection since the system is open to anyone to register as a node (even without depositing any funds.)\\nblock time is subject to fluctuations. With the default of `43204` blocks, the challenge might expire at `5 days` (10 seconds block time), `6.5 days` (13 seconds Ethereum target median block time), `7 days` (14 seconds), or more with historic block times going up to `20 seconds` for shorter periods.\\nA minority of trusted nodes may use this functionality to boot other trusted node members off the DAO issuing challenges once a day until the DAO member number is low enough to allow them to reach quorum for their own proposals or until the member threshold allows them to add new nodes without having to go through the proposal process at all.\\n```\\nsetSettingUint('members.challenge.cooldown', 6172);              // How long a member must wait before performing another challenge, approx. 1 day worth of blocks\\nsetSettingUint('members.challenge.window', 43204);               // How long a member has to respond to a challenge. 7 days worth of blocks\\nsetSettingUint('members.challenge.cost', 1 ether);               // How much it costs a non-member to challenge a members node. It's free for current members to challenge other members.\\n```\\n\\n```\\n// In the event that the majority/all of members go offline permanently and no more proposals could be passed, a current member or a regular node can 'challenge' a DAO members node to respond\\n// If it does not respond in the given window, it can be removed as a member. The one who removes the member after the challenge isn't met, must be another node other than the proposer to provide some oversight\\n// This should only be used in an emergency situation to recover the DAO. Members that need removing when consensus is still viable, should be done via the 'kick' method.\\n```\\n

Impact:

Recommended mitigation:
Implement the challenge-response process before enabling users to challenge other nodes. Implement means to detect misuse of this feature for griefing e.g. when one trusted node member forces another trusted node to defeat challenges over and over again (technical controls, monitoring).