Skip to content

Make CheckTx response indicate if a tx could never have been valid #7918

@ValarDragon

Description

@ValarDragon

Protocol Change Proposal

Problem definition

Currently peers are never punished for sending you invalid transactions. (See here) This is because its possible that for many txs that are marked as bad, there is a possible application state in which they would be good. (E.g. a tx being invalid due to wrong sequence numbers) Two full nodes can have a divergence in whether a tx is valid either due to prior txs in their mempool or from simply being on different blocks.

However it is useful to mark peers as invalid, as it increases the complexity a dishonest node must do in other to attempt to attack the network. We can't black-box mark a peer as bad for sending a tx that may have been valid from one block ago, or in the next block. However we can safely mark them as bad and disconnect from them if they sent a tx that could never be valid. This would stop malicioous nodes from being able to spam random bytes along the mempool tx channel. Furthermore, it is conceivable that for some chains, the especially burdensome to verify txs are such that they can always be statelessly verified.

Proposal

We make a CheckTx response code to allow indicating that a tx would never be valid under any state. Then the mempool would mark a peer as bad if CheckTx returns this code.

Currently the semantics of a Check Tx code is:

  • 0 Passed CheckTx
  • >0 Failed CheckTx

The proposed new semantics are then:

  • 0 Passed CheckTx
  • 1 Failed CheckTx, and the mempool should reject the Tx.
  • >= 2 Failed CheckTx, the mempool should reject the Tx, and punish the peer who sent it.

For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned

Metadata

Metadata

Assignees

Labels

community-callThis issue is to be discussed during a community callstalefor use by stalebot

Type

No type

Projects

Status

Done/Merged

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions