As populist noisemakers continue to push for blocksize inflation and services set to benefit from forcing users off of full nodes announce "stress tests" composed of transaction floods, the issue of making sure your transactions propagate with timely confirmations and your node stays online come to the forefront. Thankfully there are measures that can be taken now to which can provide benefits during a transaction flood and as fuller blocks becomes a more normal state for the Bitcoin network.
Making sure your outgoing transactions propagate and get timely confirmations is as simple as participating in the fee marketplace and outbidding spammy transactions. A safe amount to start from is likely to be 100,000 satoshis or 0.001 BTC which is an amount that if paid by transaction spammers would deplete all but the largest warchests in rather short order, but it is also low enough to be inconsequential for any transactions of sufficient value to belong recorded in the blockchain until the end of time. Incoming transactions are harder to ensure as the sender is in control of choosing the transaction fee, but discussing this issue with service providers in advance can help to prevent being surprised with problems down the line. If you are a merchant you should not be treating relayed by unconfirmed transactions as though they were confirmed until the transaction is included in a block.
Keeping a Bitcoin node happy, healthy, and online through a deluge of spam is a bit more involved, but by running the right code and settings it is possible to keep your node connected through multiple gigabytes of transaction constipation. Unconfirmed transactions live in the mempool until they are confirmed in a block or the full node bitcoin client stops either because it was instructed to do so or died in an Out Of Memory Condition or OOM Kill. There were experimental efforts in creating a trigger to have a running node empty its mempool's contents to free up memory, but due to particulars of C++ there hasn't been success with this yet. This means to keep a node online you can either add more physical memory to your machine1 or you can keep the spammy transactions from clogging up your mempool in the first place.
There are two incredibly useful tools for keeping your mempool spam free. The first is the minrelaytxfee variable which can be found in main.h along with a number of other constants.2 Setting this to 100,000 Satoshis should be enough to allow reasonable transactions to enjoy relay from your node and a place to wait for confirmation in your mempool. The second great mitigation comes from using node software which has the bastard transaction orphanage snipped. This prevents transactions for which you do not have the preceding necessary transactions from being admitted to your mempool and can prevent long chains of transaction strung together, of which previous spam "stress tests" included many. The Bitcoin Foundation's v0.5.4-TEST2 release candidate includes this improvement among others.
While particular promised transaction flooding attacks may or may not happen, there is nothing wrong with girding your node infrastructure for Bitcoin's future.
Or in an operating system like OpenBSD which imposes per process memory limits lift those limits in addition to adding more physical RAM. ↩
You can also set up your node to have this variable set in bitcoin.conf by changing the line in main.h to:
static int64 MIN_RELAY_TX_FEE = 100000;
and then in init.cpp adding
int64 n = 0;
if (ParseMoney(mapArgs["-minrelaytxfee"], n) && n > 0)
MIN_RELAY_TX_FEE = n;
printf("Invalid amount for -minrelaytxfee=: ");
in the part of init.cpp which handles bitcoin.conf flags. Further you may add another line to init.cpp in the section containing help information for the flags reading:
" -minrelaytxfee= t " + _("Set the minimum fee in satoshis for a tx to be relayed by this noden") +
Bitcoin Core 0.9 and later already have this implemented differently using a lot more code and accepting decimal amounts of BTC rather than integer Satoshis. ↩