Thread

Accurate description. Yet there are two claims that just contradict each other and cannot be squared: 1) consensus and (mempool) policy are truly separated. If so, then the latter is up to each client implementation - or rather each individual node config. If we believe that ( I do, and based on your comment so do you ) then we *must* accept node runners' autonomy over their mempool. Even if it means that it will no longer reflect the perfect world for dependent layers/system (e.g. lightning) 2) there is an objectively "optimal" mempool (the one that 99.99% approximates of what will be mined by miners) that should be adhered to by all nodes. If that is the case, then the policy settings of the 95%-dominant client are *effectively* like consensus. And should be subject to the same level of scrutiny as a consensus changing soft fork. What bothers me in the current discussion is that Core try to have *both ways*. They (Lopp being the most vocal) claim it "just a policy setting", i.e. #1, where plebs dont get a say since it is Bitcoin Core dev business. And at the same time claim that we have to have a "common mempool" (i.e. #2), too, because otherwise it would be detrimental to the overall network So which one is it??? If The Mempool™️ is a common (#2), then you must allow broad discussion. And you should really make it part of protocol consensus. Otherwise let people run their own settings and leave them be. tl;dr You can't have your cake and eat it too. ---- Detour: What really happened imho is that Core and layer2 devs have always banked on the implicit assumption that mempools are virtually identical among nodes - because they all ran the same software, with the same default settings. They are now caught with their pants down, as this was always a lazy assumption (one I would have made too!! not prentending to be smart here), and are trying to force the reality fit the model.