@VeritasSapere
As I've told you before, your responses are by and large insufficient. In most cases, you are merely saying "I disagree..." or "I think that..." or "I don't think that..." I cannot refute an opinion if you provide nothing to support it. Your discussion of orphaned blocks is completely absent of facts or proof; it is just tortured logic. When your arguments repeatedly boil down to mere opinion rather than logic based in facts, there is little point in arguing. My points still stand.
And seriously, I just explained how spam is already defined by the Core software and how it can be individually set. And still it's impossible to identify spam? This isn't about fees; it's about blockchain and UTXO bloat and maximizing efficiency/minimizing unnecessary throughput. You think it's more important to forego other methods of scaling so that we have to subsidize people who want to send cents, fractions of cents? Subsidize spam like Coinwallet? Not interested. You need to lose this one-track mindset.
And political commentary, by definition, cannot address technical flaws, nor the issue of ignoring engineering standards. The premise that politics can override technical knowledge and expertise is absolutely unacceptable. If that is the case, then by definition, breaking the protocol is acceptable for political reasons. WTF is the point of supporting bitcoin, then, if its procotol is constantly at the whims of a political majority? Why do you think "consensus" was established as a principle in the first place?
Your arguments about governance, again, fall on deaf ears. It's meaningless hot air.
Show me alternative implementations with widespread support. No go? Build them yourself. I don't see anything here to talk about. Again, you say you think the BIP process is a problem?
Then provide your primer on what the governance model is supposed to look like. Bring it to the devs, see if anyone supports anything you are saying. Because if the only major code contributors on your side are Gavin and Hearn, you've already lost.
What I see from you is all complaints, no action. Bitcoin is a form of democracy
I have already responded to most of the [technical] issues you have raised there and you do not acknowledge my counter arguments because they are political in nature.
I do not think that BIP101 threatens network security, and the t[h]reat of a political civil war should not sufficient reason to not support a contentious fork.
I think that fifty one percent is enough to justify a fork
miners will not be effected by an increase in the block size
On a fundamental level, I completely disagree with the first four statements. (The last is a technical point which you have not sufficiently proven.) You believe bitcoin is a democracy, and that 51% (aka a 51% attack through argument) is sufficient to hard fork. I believe your position is at odds with the ideas of "valid blocks" and the "consensus mechanism" stated in the whitepaper.
You've basically conceded that a civil war with multiple surviving blockchains is not only acceptable -- but it almost seems as if you think it's an optimal solution. If you think bitcoin is worth fracturing along the lines of something so insignificant as block size, this is another fundamental impasse.
And re XT being buggy? Yes, it is. That's what happens with little to no peer review. Irresponsible to release the code as such. One recent example:
https://www.reddit.com/r/Bitcoin/comments/3kenp1/stress_test_commence_as_of_now_were_seeing_23/cuwxvbzYour mempool limiting technique creates a cheap network bandwidth DoS attack.
The problem is Gavin's patch evicts random transactions (and their descendants) from the mempool without regard to what fees anything paid; in Bitcoin we use paying fees to limit DoS attacks, so anytime a transaction can be broadcast without having a high probability of eventually paying the fee is very bad. Evicted transactions aren't recorded, so if a peer rebroadcasts them to you you'll redownload them. Equally that makes up a bunch of space for different rebroadcasted transactions respending UTXO's that were previously spent. Either way, bandwidth is being used that isn't being paid for.
This is all very well known stuff, and dealing with it is most of the reason why Core is actively working towards implementing a mempool sorted by fees. That you quickly merged Gavin's patch is a sign you don't have much peer review, given that a multiple simpler, working, alternatives exist if you just want something fast to implement. (e.g. the feerate tier idea discussed on IRC/github)
More importantly, though, BIP101 breaks the consensus mechanism and introduces a scaling regime with completely unknown conditions.