There is primarily two ways to flood block chains, one is to create very large transactions, the other is to create large number of transactions.
To create large transactions, one must have wallet which hasn't been optimized recently. This is because when you send a transaction, you're actually using unspent outputs from previously received transactions and to get the correct amount, one or more these needs to be used. If coin doesn't support optimizing wallets, user must make sure there is as many incoming transactions as possible without any outgoing transactions.
The sum of the transaction should contain no zeroes, preferably numbers closer to 9, so for example 9876543.21... This is to make sure for each of the denominations (9000000.00, 800000.00, 70000.00, 6000.00, 500.00, 40.00, 3.00, 0.20, 0.01 and network fee), the wallet needs to use more than one unspent output. The example amount and denominations are for coin that has dust threshold of 0.01. Dust threshold is smallest amount that can be sent. For smaller dust threshold, all denominations should be equally smaller, for higher dust threshold, equally larger.
There is two related properties of a transaction, mixin and anonymity level... Mixin is how many dummy outputs are added to the transactions to mask the true source address of the transaction. Anonymity level is basically one less than mixin, as in smallest case, only real unspent outputs are used, there is no dummy outputs collected from previous transactions by other users.
To create very large transaction, mixin must be large enough that node validating the transaction has to spend as much time to verify the outputs as possible, but small enough that the transaction does still fit within maximum block size after the block header.
To create large number of transactions, one must have a lot of deposits with small amounts. Like with the previous case, the denominations should be close to 9, but in this case sum of the denominations from each source transactions in each step should not equal to multiple of 10. This is to make sure the output of the fusion transaction can be sent again to create more transactions.
First step is to create as many fusion transactions as possible to combine the unspent outputs to larger denominations. Because the sum of denominations is not multiple of 10, there will be new unspent outputs returned that can be used for more fusion transactions.
After coins from first step are returned and unlocked, user must create as many fusion transactions as possible and send them again.
After coins from second step are returned and unlocked, the step can be repeated until the count of unspent outputs is less than the minimum threshold or sums of all denominations are less than 10.
Best way to avoid flood is to make sure any variable-length field in the transaction has maximum limit. This includes the "extra" or memo field, transaction inputs and total size of the whole transaction. For mixin, 50 is usually a good limit, it will still allow good level of anonymity (less than 2% chance to find real sender).
Another good way is to limit the number of fusion transactions. Even though fusion transactions are necessary to make sure normal transactions cannot grow too large, sending too many of them too fast can slow down all the nodes validating them as they are stored in memory and are shown in block explorer and some wallets with graphical user interface (GUI).
Most coins have low limits for size of fusion transactions, so normal transactions are more likely added to new blocks first. This means most of the fusion transactions are queued for adding to subsequent blocks.
