The node could see that all of these chained transactions stem from one transaction. It could block any transaction that has an ancestor of that particular transaction. If the node kept a database of the spam transaction chaintip, it could quickly determine whether the parent transaction was part of the spam chain and block the child.
That is actually a very good idea and could be reasonably feasible. Hopefully keeping the root TXs in the internal DB won't consume too much memory and checking their existence won't consume too much CPU.
It would require a soft-fork and we all know how long soft-forks take and their consequences.
As long as the devs are smart enough (I do hope they are) to not use an algo that has an ASIC (e.g. sha256 or scrypt) it could potentially work. How does bitmessage implement this and how do they determine the difficulty?
But this soft fork is backwards compatible. It would only make a difference when the network is flooded by TXs and it encourages people to update their clients because updated nodes would reject their TXs otherwise. Don't worry about the algorithm, it can safely use something such as SHA256 but have some bits swapped in the end or in between so that a plain SHA256 ASIC would be useless.
BitMessage uses SHA256 very similarly to bitcoin but the same ASICs can not be used that are used for bitcoin mining. BitMessage has a fixed difficulty on the protocol level. Not very good but it's way better than having no difficulty at all because it makes attacking many times more expensive. If Bitcoin was to implement TX mining, then its difficulty should be adjusted according to the number of unconfirmed TXs.
There is a patch called Replace-By-Fee where transactions spending the same inputs can be replaced with another that has a higher fee. The mempool should not drop "less important" transactions because some of them could be legit. Rather, miners should choose which transactions to include by their priority, which I believe already happens.
It's good to know that such a patch exists but it would be better if it was included in bitcoin-core.
The mempool should drop "less important" TXs because who cares if some of them could be legit if the node is running out of RAM. Dropping less important TXs is the lesser evil in comparison to an out of memory exception
. All it can do is to politely tell the other node that their TX could not be accepted at this time and that they should try sending it again later.
You should never see that your transaction be rejected, simply that it will take a while to confirm. I believe that all transactions should confirm eventually. Instead of having no chance for a low fee transaction to confirm, there should be a chance eventually for it to confirm in the future. The RBF patch allows you to replace the transaction in the mempool so that it has a higher priority with a higher fee, thus allowing your transaction to confirm sooner (hopefully).
I disagree but I might have used a wrong term. Instead of rejection I would rather call it postponing. The honest nodes whose TXs are postponed by neighbouring nodes must attempt to resend the TX in gradually increasing intervals. If a node resends the TX too often they would be banned by their neighbours.
"The 1 MB blocksize limit was only put in as a tx spam limiting measure"
and
"The tx spam that is backing up in the memepool is proof we need to remove the blocksize limit"
Only one of these statements can be true.
Pick one.
I can't put it any better than that. People saying that we need to raise the blocksize limit to
prevent DOS is utterly and obviously senseless, illogical, and untrue; contrary to all reason or common sense; laughably foolish and false*.
https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/csvoxvp*http://dictionary.reference.com/browse/absurd
You are absolutely right. I have previously proposed that every 144th block should have the technically maximal possible size or some other giant size such as 64 MiB just to clear the backlog of unconfirmed TXs once per day. Other blocks should have a size of 8 MiB which I believe is more reasonable than 1 MiB. That limit should not be raised in the future but instead if needed then the maximal size of the 144th block could be increased.