The transaction deemed invalid (due to reason explained above), so it won't even enter mempool or broadcasted to another node. Only few node or server which will be slightly affected from verifying invalid transaction.
Additionally whether the bad user uses full node or spv wallet, other node or server (such as Electrum) would block them after reach specific threshold.
Topic: How does the bitcoin network prevent network spam? (Read 79 times)
Most of the malicious acts such as your question are prevented by nodes enforcing "standard rules" because the protocol can not change and it allows a lot of them to happen. For example there is nothing wrong with multiple transactions spending the same output according to the protocol as long as none of them are confirmed.
One standard rule is to prevent double spends which means when a UTXO is spent already it can't be spent again and the node's mempool rejects the conflicting transactions and can possibly even ban the misbehaving node which would prevent further "spam".
RBF adds flexibility to those rules as HCP explained and in that case the "spam" is prevented by increasing fee until the spammer runs out of money.
One standard rule is to prevent double spends which means when a UTXO is spent already it can't be spent again and the node's mempool rejects the conflicting transactions and can possibly even ban the misbehaving node which would prevent further "spam".
RBF adds flexibility to those rules as HCP explained and in that case the "spam" is prevented by increasing fee until the spammer runs out of money.
One of the rules is that the fee for RBF transactions must increase. If you spam the transactions and don't increase the fee, they'll be rejected. So, at some point, you either run out of available coins to increase the fee, or one of the transactions gets confirmed which would immediately invalidate all the others and end the attack.
Additionally, if you send another transaction using RBF, the "original" transaction is then dropped from the mempool.
You can see the specs in BIP125:
If you're not trying to RBF, and simply attempting to double-spend... then the transaction is generally just rejected outright, because you're trying to double-spend
you'll get "txn-conflict" type errors because a transaction spending the same UTXOs already exists.
Additionally, if you send another transaction using RBF, the "original" transaction is then dropped from the mempool.
You can see the specs in BIP125:
One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,
1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
2. The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)
3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.
4. The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
5. The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
1. The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
2. The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)
3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.
4. The replacement transaction must also pay for its own bandwidth at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
5. The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.
If you're not trying to RBF, and simply attempting to double-spend... then the transaction is generally just rejected outright, because you're trying to double-spend
you'll get "txn-conflict" type errors because a transaction spending the same UTXOs already exists. 
Let's say a bad user spams the network with transactions using the same inputs but every transaction has a other output. I refer to different outputs (or inputs if the bad user has a lot spendable outputs) because I guess theirs a rule which rejects transactions with the same txid as another transaction which is already in the mempool. What are the methods used to prevent such attacks? Some could send an x amount of transaction and at the end only one gets confirmed and the bad user only pays one time fees because the other will get sorted out of the mempool. But they all get into the mempool because their valid and they will take up huge space and network ressources. So fees won't stop him. Does the ip address from which the bad user sends the transactions play a role? Are they getting blocked after a period of time? What if he sends from different internet networks?
Jump to: