I think they are waking up to the fact that they have pissed off a large percentage of their user base, and by user base I do not mean reddit accounts or phone wallet users, but the other infrastructure providers who make bitcoin work. (i.e. the developers behind coinbase, bitpay, circle, wallet developers, exchanges, etc).

These developers have put in a tremendous amount of time, effort and money in building toolkits around the open bitcoin protocol. They require that protocol to work. They do not want to see those investments be thrown away and forced into new off chain protocols (LN and SC) which even if they work require extensive effort to transition to (and that ignores philosophical differences). They also do not want the added risk of being forced to rely on unproven technologies for their mainstream offerings and instead favor the proven mainchain behavior.

The core devs have displayed themselves as poor partners to the rest of the bitcoin infrastructure community, because they are acting as if Bitcoin is still a toy for them to play around with as they see fit. This may have been true in 2010, but it's not today. It was one thing for them to dictate fee reductions as the price rose past $10 and the $100, but it is another thing to force the entire software infrastructure off the mainchain. This community wake up is not good for them long term.

I think plenty of people have been doing so. The problem is since their is no "Bitcoin organization" none these accurate voices are speaking from any position of authority and instead just get drowned out. And if you view the core devs as the closest thing to a Bitcoin organization, then the fact that some of them are the ones spreading FUD makes it twice as hard.

It is very admirable that Satoshi stepped back after Bitcoin got going (and has yet to cash out his coins). However I think it would have been much better if as he was leaving he wrote and communicated what he thought the long term direction should be along a variety of aspects. For example from his writing I think he took it for granted that he thought the 1MB should be raised over time and that bitcoin should be structured so that most people could work directly with the MC. A simple 5 pages could have communicated a lot. None of it would be binding and he would have stated that this is what he wanted but people now decide. But by doing this it would later be easier for people to refer back to the original vision in a clear manner.

The problem is Satoshi left without explicitly clear long term direction. The result has been schism over how Bitcoin should evolve. Personally I am fine with that because it makes it harder for change Bitcoin at all, but the problem is there were a few basic changes that were needed to achieve his vision that now are hard to do.

Exactly, great way to put it.

This is what is being missed in the centralization fear mongering. Because of the way Bitcoin is structured even with further centralization it is still relatively easy for SPV light wallets to verify for themselves the validity of a payment to an address they control. The two ways to attack this are either 1) block re-orgs which require 51% style attacks or 2) creating false header chains (hard) plus making sure the SPV wallet can not connect to a single honest node (very hard).

Centralization also does not make denial of service attacks more likely. Even with more pool centralization SPV light nodes can connect to honest miners to include transactions in their blocks.

The 1MB limit will become in itself become a denial of service attack, so far it is the only real threat right now.

1) Attacker: Miners
The key question here is do larger blocks even change the mining ecosystem, because if larger blocks do not effect miners then the point is moot since the attacks are the same with or without larger blocks.
There are good reasons to believe that larger blocks do not effect mining. Miners already have centralized on pools, which themselves are large enough to scale up resources. Pools do not have to be physically close to miners and can (and should) migrate to well networked regions and cloud services.
Miners themselves already use the stratum protocol that require < 1kbps connectivity, they are not impacted by or see any effects from larger blocks. The pool handles the block, while the miner just processes a data packet that is the same size regardless of blocksize.

2) Attacker: Nodes
As you point out, all you require is a connection to one honest node and that honest node can expose any attack. If 50% of the P2P nodes are coordinating an attack and a SPV wallet connects to 8 random nodes, then the probability of success is 1/2^8 or 0.39%. This attack is very difficult with a larger number of nodes.
In the case where P2P nodes become highly centralized (let's say they are reduced to 25 very large entities), then it is likely that several of those nodes would be trusted volunteer efforts (think an EFF node) or run by trusted entities (think a shared ivy league university node) and SPV wallets would be programmed to require connections to a least a few trusted nodes. This is probably an even more difficult attack than today where we have 6K nodes, since it is relatively easy to spin up 6K nodes in AWS for the short period of time needed.

I think there is a lot beyond bugfixing and trivial usage qualities they could compete on. There are real optimizations that could be done with pruning and other enhancements. Today these are being ignored for RBF changes and focus on LN and SC development. A set of devs working on an alternative core implementation that dedicate their time to improving the user experience, would develop a better implementation that attracts people over time.

My pizza place uses BitPay, they accept blind pay-to address transactions with no registration or anything as zero confirm transactions, usually clears in 2-3 seconds, has since 2013. There is zero recourse for BitPay if I successfully cheat, but the network prevents that so BitPay works.

Odalv, you are so absolutely wrong here

And Peter, myself, cypher and others already stated this as the original argument that 0-conf(+RBF) are insecure. We are discussing today's 0-conf (as-is), which functions good enough in the real world.

You've started to behave like TBTP

Have you heard of this little company called BitPay, you might want to Google them. They've accepted zero confirm transaction since 2013 without issue.

We are not discussing theoretical what-if scenarios here. This is real world use of ZCT and evidence Bitcoin functions good enough here for ecommerce.
 
But you've already ignored this, you either aren't even bothering to read replies and just screaming, or are incapable of rudimentary reading comprehension.

It was BTCChina Pool that only processed 81KB of transactions. If I was a miner on them I'd move to someone else.

And who here besides you has made the statement that zero confirm transactions are 100% secure, no one.

As Peter said they are shades of gray. Well formed zero confirm transactions are not absolute but pretty reliable, in the same manner that 1-confirm transactions are not absolute but even more reliable and so on.

It's only malformed zero confirm transactions that are explicitly not reliable, but as explained those are easy to spot on the P2P network (and yes even a P2P network with cheaters, terrorists, Russia and China)

You should be a consultant for Bitpay and Coinbase warning them of the dangers of ZCT and how they need to stop. I'm sure they will gladly benefit from your insights. 

So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.

Now that's a thought.

Let's take it farther, are they in fact being coerced against their will to take these positions. Given they fact that their arguments are obviously FUD and yet they supposedly understand Bitcoin, it might be their way of expressing there is a state gun to their head to weaken bitcoin. The full-RBF proposal is one such absurdity

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

That is awesome, is this on the Android app, in which case how did I miss seeing that...

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I was referring to RBF as full-RBF in your terminology, we are in agreement on the above.

Except that Bitcoin does function as a real-time system for most use cases today perfectly fine. There is an entire Bitcoin ecommerce industry that proves you wrong.

The replace-by-fee mechanism allows the sender to change a transaction and increase a fee, while the child-pays-parent mechanism allows a receiver to add a fee to an existing transaction.

And this is why RBF is completely contrary to the ethos of Bitcoin. Bitcoin was designed so that transactions can not be canceled and so that once a receiver takes control of BTC they have full control. The P2P network rejecting 2nd seen transactions is one aspect of that mechanism, the blockchain record is another.

RBF transfers power from the receiver and puts it back in the hands of the sender. With RBF after two people make an exchange, the sender now has the ability to reach into the receivers pocket and take the sent BTC back. This is horrifying and this is not Bitcoin. RBF complete destroys zero confirm transaction confidence, which the P2P network provides today.

Those were 1.2GB DRAM nodes, which are very limited VM instances with only a couple 100MB for the memory pool.

The poster said that his 2GB and 4GB DRAM nodes were fine, and they should be through 200MB blocks.

If this is a true demand situation based on the recent price movement, then if we have a real bubble move the network is simply going to not be able to handle demand. Increasing fees is not an option because there isn't enough space for everyone regardless of the fees they offer.

What is happening right now shows that P2P nodes can in fact handle larger blocks, they are processing the transaction volume fine and have enough BW to forward transactions. In fact by not clearing transactions in blocks and causing the memory pool to increase beyond what it should, the 1MB limit is probably more stressful on nodes than simply letting larger blocks get processed....