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
if (mapArgs.count("-minrelaytxfee"))
{
int64 n = 0;
if (ParseMoney(mapArgs["-minrelaytxfee"], n) && n > 0)
MIN_RELAY_TX_FEE = n;
else {
printf("Invalid amount for -minrelaytxfee=: ");
return false;
}
}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. ↩
> Incoming transactions are harder to ensure as the sender is in control of choosing the transaction fee,
Replace-by-fee (RBF)? Even First-seen-safe replace-by-fee (FSSRBF)?
F2Pool and others are running this patch, and you can broadcast directly to them http://f2pool.com/pushtx (if you have obtainted a code from them)
Interesting.
Exposing minrelaytxfee as a user definable parameter in the client would be useful, or setting it so that if memory is running out, it gets changed to deflect spam. Only a small handful of people compile their own client and can make this setting in the source.
Also, people who do these stress tests are no different to Low Orbit Ion Cannon users attacking VISA. Any company that announces a "Stress Test" without the agreement of 100% of nodes is a spammer, and spam is illegal. Anyone wanting to stop these absurd and destructive tests should make a threat of a lawsuit for disrupting a financial network, and if they do it, sue the imbeciles that launched it.
Loathe that any ethical man is to turn to the State and its "law", most people who do not have this inhibition will have no problem calling the "authorities" if a flood attack is launched with advance notice from the people doing it. BitPay gets hammered just like everyone else, in these bogus "tests" so you can expect someone like that to drop a dime. The people launching these unwelcome and unnecessary network attacks will be dissuaded, if not by reason, then by other means.
If these people were really interested in modelling the Bitcoin network, they should build a complete model in IBM Watson, including all nodes, historic difficulty state, and complete copy of the Blockchain, and then run it under different scenarios. They can then push and pull parameters and introduce new behaviour until the desired outcome pops out. We know who should not set the terms of the "correct" outcome, obviously.
IBM's Watson isn't in my WoT.
More seriously it is hard to give much weight to the proposition that people using Bitcoin seriously aren't compiling and patching their own client and node software. Just trusting a black box with the money is for fiat.
Its very unlikely that Bitcoin is going to remain in the hands of a relatively small number of people in the long run. In the same way that the people who used to use BBS systems in small numbers that are dwarfed by the number of internet users, Bitcoin will undergo a similar transformation, with similar beneficial effects, only this time, penetrating more deeply into society at every level than what is simple net access today.
If it is the case that Bitcoin access is not going to remain a tool in the hands of people who compile their own clients (in fact this is already the case, as millions of people use third party access tools like Blockchain) then its a matter of how those people access it, and who is in control of the gateways and software.
I say that it is better for everyone if MP is the multi billionaire that is in charge of a large section of that economy, rather than some American KYC/AML promoting parochial psychopathic eater of Freedom Fries, that is willing to steal money from a man who is not even convicted of a crime that should not be a crime.
All I need to make this determination is MPs public and vigorous defence of the privacy of one of his clients against US Government inquiries, at risk to himself. Compare and contrast that with the behaviour of other business owners who terminate accounts simply because they appear, by the most tenuous of connections, to be using their own money for purposes that are currently illegal, or who refuse to serve people without submission of a complete personal dossier, including future use of their own "money".
If these types and their companies are not to dominate, then someone has to develop the services and software to destroy the value of using them. It is inevitable that this is going to happen, and it can be MP or anyone that knows right from wrong, and is willing to put their neck on the line because their honour and word are actually worth something.
Failing this, we can expect Bitcoin to be deliberately broken and converted into a surveillance system, as Hearn has openly proposed, with his plan to add address blacklists into future versions of a US Reference Client.
If ethical companies do not become the de facto standard with the biggest customer bases and client respecting practices, its inevitable that the version of Bitcoin that reaches mass adoption will be broken. It isn't unreasonable or unrealistic to imagine an outcome where this is not the case, and where there are substantial numbers of users of Bitcoin; the very idea of Bitcoin itself was thought to be an impossibility until the software emerged.
Finally, there are other advantages of being in charge of the perception of Bitcoin and millions of users; they act as a deep shield to protect the inner circle. Without the resources of a billionaire with hundreds millions of users, and the ability to buy law to order, any small group of people is vulnerable to extinction. As the number of Bitcoin users and services grows, anyone who is not growing proportionally will inevitably shrink in importance and power.
And an idiot proof WOT is coming… mark my words!
Minimum fee should really be per byte, not per tx. Min. fee of 1 mBTC won't do much good if spam tx is 10^5 bytes each.
The client actually calculates the fee as per kilobyte.
The point is sound tho, it should be per byte, and for that matter all discussion in b-a of the concept was per-byte.
Indeed it is.