rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-10-05 📝 Original message:On Mon, Oct 5, 2015 at 3:56 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > 1) ignores him, which is against the established criteria that all technical > objections coming from anyone must be addressed until that person agrees, so > that a change can be uncontroversial. If the group moves forward with the > change, then the "uncontroversial" criteria is violated and then credibility > is lost. So a new governance model would be required for which the change is > within the established rules. > > 2) respond to his technical objections one after the other, on never ending > threads, bringing the project to a standstill. I don't agree-- I think you've made the mistake of just accepting the particular framing that Mike has provide; one that (no shock) only supports his conclusions. I am aware of no instance where an active contributor to core has made the claim that no change to consensus can happen without 100% support (and doubly so, 100% including people who are expressly trying to disrupt the project by posing opposition which, as you note, is largely unrelated to the merits of the proposals). Mike has lead you to believe people have claimed this, but no one has-- it's a view which is simple, clear, and completely not reflecting reality. Don't fall for strawman arguments. In this situation it is also a particularly strong apples/oranges comparison: Soft forks can happen at any time at the whim of miners-- no technology which we are aware of (beyond the technology of centralization) is able to prevent them-- they are not necessarily even detectable; on this basis they are categorically different than hard forks. Moreover, the space of soft-forks the contributors to Bitcoin Core would ever consider is a tiny space of all possible soft-forks, and are ones which cannot be rationally understood to meaningfully undermine the properties provided by the rules enforced within the software; again making them different from some other proposals and of a lesser concern. Finally, the behavior of the technology arising from the inherent compatibility, radically lowers (in most of our experience and opinion) the cost of deployment; again-- making them different. They prevent a industry wide flag day, and tight release synchronization which is harmful to decentralization promoting software diversity. As I think I commented in one of my messages-- I respond to the technical arguments not because I believe they are earnestly motivated, but because they provide an avenue for learning for myself and others. Even someone trying to disrupt the process and nothing else can help us learn by acting as an adversary that causes us to extend our minds and understanding. The process for CLTV has been ongoing for something like a year and a half and has little risk of being substantially disrupted at this point.