Remote DoS by memory exhaustion in the TxPool using MsgTxTy

[obscuren]

Each new transaction send using the MsgTxTy message is queued in the TxPool. An attacker can supply transactions at a higher rate than the time the victim node requires to evaluate each transaction. For example, in a 100 KByte/sec connection to a victim node the attacker can transmit approximately 1000 transactions per second, while verifying the transaction signature may cost more than 1 msec. This can lead to the accumulation of messages in the queue and the consumption of all available memory. Also the attack can be used to delay the processing of transaction from other peers.

Several fixes are possible, for example:

• Establish a maximum number of transactions that can be queued per client.
• Block the client if the number of transaction queued is above a predefined limit.
• Force node isolation by continued supply of MsgPeersTy messages

[ebuchman]

Funny, was just thinking about this problem today - is a serious issue. Not sure you can just have a limit, since a bad peer could just fill your limit with bad txs and then you're not really contributing to the network.

We could have nodes run the tx execution and punish peers sending bad execution or executions that run out of gas, but these executions will have to be redone when txs come in the block possibly in another order, so that's also not that nice.

One thing we can maybe count on is more of the nodes to be mining (say, unlike btc), in which case they will verify the txs, so its less of an issue. But at the least the node should check that the sender has at least as much funds as gas included in the tx (I suppose you can ignore value, ie the comment in ValidateTransaction())

Further on that thought - if the intention really is to keep this ASIC hard and/or move to PoS, we will have much closer agreement between the validating set and the mining set, so again this won't be as big an issue. Can we rely on that? What is the significance/importance of having nodes propagate txs if it turns out those txs might actually be invalid executions (and hence impossible to get included in a block)? It's just DoSing the network.

[ebuchman]

Been thinking about this more. We can mitigate a big part of the attack if the transaction pool tracks an intermediate account balance state. Otherwise I can send a billion transactions each sending 0.01 eth from an account with 0.01 eth and the peers will store all of them but only one will get mined. But if they track in the txpool such an intermediate state they would notice the double spend immediately and drop them, like in bitcoin, stifling the RAM DoS. Is that feasible? What do you think? Can we just use the ChainManager's transState?

[obscuren]

The transient state is intended for such use though I don't think this is the right solution.

There might be good reason to allow for transactions with the same nonce and not being necessarily an attempt to double spend. For example what if you create 2 transactions each containing the same instructions, though, with a different gas_price?

[ebuchman]

thats a reasonable concern. surely someone should enable that but should it be default behaviour? reminds me of the bitcoin Replace By Fee tools patch. maybe someone from the community will want to maintain a branch that supports that. also I notice the "check account has sufficient balance" is commented out but I don't understand why

[tgerring]

Is this issue still open? If so, what changes are needed to close it out?

[obscuren]

Most of these have been addressed in the TxPool. Will close