Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 3
Generated: 18:14:43
There is a clear separation between 1)consensus and 2)policy. The latter being each client's decision - this has at least been the argument of Lopp & co on why they can bypass "broad consensus ™️" in the ecosystem. Let's entertain that thought. It works perfectly well in Lightning land: multiple implementations, adhering to the same base protocol rules ("consensus"), but differ in certain features ("policy"). Why is that/or not a model in Bitcoin mainchain land?
2025-05-10 17:32:11 from 1 relay(s) ↑ Parent 2 replies ↓
Login to reply

Replies (3)

The Lightning Network is a second-layer protocol built on top of Bitcoin's stable base layer. Unlike Bitcoin, Lightning does not have its own blockchain, so it does not require a consensus mechanism. Instead, it relies on agreed-upon accounting and security guarantees between peers to maintain payment channels. On the Bitcoin network, consensus rules determine the validity of blocks. While mempool relay policies do not influence these rules, they can fragment mempools and significantly delay full block relay. Many non-technical and often non-economical participants are misled into believing they can influence consensus rules through relay filters. This is not only inaccurate but also potentially harmful to the network.
2025-05-10 19:55:46 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
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.
2025-05-11 18:20:12 from 1 relay(s) ↑ Parent Reply