Description
Feature Request
Ban peers that send transactions that could never have been valid (due to misconfiguration of the peer for example).
Summary
ResponseCheckTx should be extended with a txNeverValid field that allows the application to inform CometBFT that the transaction could never have been valid. If CometBFT receives this code, it will disconnect from and ban the peer that sent this transaction.
Problem Definition
This issue is the result of RFC101.
The main motivation for the implementation of this feature is to prevent a node being spammed with transactions that could never be valid. As whether a transaction could never have been valid, is application specific, we allow the application to inform us via a special code.
Implementing this can increase the vulnerability of a node in case of a bug with the CheckTx call that would ban all peers. For more details, please read the RFC and the discussion around it.
Proposal
After users raised potential security issues that could be resolved by having this features, and operators foreseeing much quicker debugging of issues that could cause gossip of transactions that are never valid, we decided to implement this feature.
However, as the the p2p specification is still in development, and we are not able to clearly foresee the potential effects of peer banning on overall network connectivity, we will implement this feature in two phases:
- abci: Add
txNeverValidfield toResponseCheckTxand output error #624
Add another field toCheckTxsignalling that a transaction could never have been valid. CometBFT will output a special log message (containing information on the sending peer) in case this flag is set, thus allowing operators to quickly discover potentially faulty nodes. We should decide, whether we want to forward this log message to the sending peer itself. - Phase 2: In addition to outputting a log message, ban the sending peer and disconnect from him.