{"type":"rich","version":"1.0","author_name":"npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h","author_url":"https://nostr.ae/npub1j3u42vq63qzs2nyddgkf4s4t7pa85x855vas54e6yauxsvpf2wcsacwg9h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nHello,\n\nFirst, this only makes reference to hard forks not to soft forks. This\nis very important because we are trying to apply a hard fork\nrequirement to a soft fork procedure which obviously won't work.\n\nYour statement that 'all objections coming from anyone must be\naddressed until that person agrees' is not applicable in reality. What\nif that person objecting is explained several times, with plausible\nand verifiable technical arguments, and that person still doesn't\nagree (either on purpose, either really doesn't understand the\nexplanations)? What will we do in this case? Assume it's controversial\nbecause someone refuses to or simply doesn't understand? This seams at\nleast a little bit unfair.\n\nIt's like we are in a court room where a text from a law (like this\nrequirement from that BIP) can be twisted and interpreted in various\nway in an endless debate. We cannot apply everything as-it-is-stated\nword-by-word and apply it _blindly_ like robots in every situation,\neverything always depends on context and other factors.\n\nFor example, I don't see this controversial nor a violation of the BIP\nrequirements. Mike had some fair objections, they were explained by\ngmaxwell and Jorge, everybody understood. The explanation is clear,\nwith plausible practical examples, so from my point of view the\nobjections have no arguments to sustain the claim. I don't see\nanything controversial here. Now of course it's Mike's right to reject\nthose explanations, but what's the 'controversial' here?\n\nOn 10/5/2015 6:56 PM, Sergio Demian Lerner via bitcoin-dev wrote:\n\u003e Some of the people on this mailing list are blindly discussing the \n\u003e technicalities of a soft/hard fork without realizing that is not\n\u003e Mike's main intention. At least I perceive (and maybe others too)\n\u003e something else is happening.\n\u003e \n\u003e Let me try to clarify: the discussion has nothing to do with\n\u003e technical arguments. I generally like more hard forks than soft\n\u003e forks (but I won't explain why because this is not a technical\n\u003e thread), but for CLTV this is quite irrelevant (but I won't explain\n\u003e why..), and I want CLTV to be deployed asap.\n\u003e \n\u003e Mike's intention is to criticize the informal governance model of \n\u003e Bitcoin Core development and he has strategically pushed the\n\u003e discussion to a dead-end where the group either:\n\u003e \n\u003e 1) ignores him, which is against the established criteria that all \n\u003e technical objections coming from anyone must be addressed until\n\u003e that person agrees, so that a change can be uncontroversial. If the\n\u003e group moves forward with the change, then the \"uncontroversial\"\n\u003e criteria is violated and then credibility is lost. So a new\n\u003e governance model would be required for which the change is within\n\u003e the established rules.\n\u003e \n\u003e 2) respond to his technical objections one after the other, on\n\u003e never ending threads, bringing the project to a standstill.\n\u003e \n\u003e As I don't want 2) to happen, then 1) must happen, which is what\n\u003e Mike wants. I have nothing for or against Mike personally. I just\n\u003e think Mike Hearn has won this battle. But having a more formal\n\u003e decision making process may not be too bad for Bitcoin, maybe it\n\u003e can actually be good.\n\u003e \n\u003e Best regards from a non-developer to my dearest developer friends, \n\u003e Sergio.\n\u003e \n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v2.0.22 (MingW32)\n\niQEcBAEBCAAGBQJWErRQAAoJEIN/pSyBJlsRxJMIAI9eoPny6B2VOH/wSkfeeVbu\nbZ+0ZBLfDIwzQ2Tqn0DZQ8TWHfHPHacA7IxtTRnkSqPTMcDUgZ5/URBE4Tt8p2F2\nzDda0NjqMUIJIBkLHRHzApRTK+BcshtarSbGJOr7HUaOb2hyDnQp1bzOMPGpIdTq\nYA5EY39SdzzJaF7uto/bhFj6g51kdxux2epbmbaJjUHFUO1+6RAw/irI6hkyzWzi\nVS8l6ZpXiaV3Y1pU+Nc60sa4GacYwKvFmvve7DTIYVsPV6KzJmbT924n5TW3191H\nJBxRnUUqoWEae/h85pOQiYbJGX/EtXOmy2CZcGm0TkL3vXsAwxiDQyz8NlNyAOI=\n=ClSy\n-----END PGP SIGNATURE-----"}