{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-10-05\n📝 Original message:Hey Sergio,\n\nTo clarify: my *single* objection is that CLTV should be a hard fork. I\nhaven't been raising never-ending technical objections, there's only one.\n\nI *have* been answering all the various reasons being brought up why I'm\nwrong and soft forks are awesome .... and there do seem to be a limitless\nnumber of such emails .... but on my side it's still just a single\nobjection. If CLTV is a hard fork then I won't be objecting anymore, right?\n\nCLTV deployment is clearly controversial. Many developers other than me\nhave noted that hard forks are cleaner, and have other desirable\nproperties. I'm not the only one who sees a big question mark over soft\nforks.\n\nAs everyone in the Bitcoin community has been clearly told that\ncontroversial changes to the consensus rules must not happen, it's clear\nthat CLTV cannot happen in its current form.\n\nNow I'll be frank - you are quite correct that I fully expect the Core\nmaintainers to ignore this controversy and do CLTV as a soft fork anyway.\nI'm a cynic. I don't think \"everyone must agree\" is workable and have said\nso from the start. Faced with a choice of going back on their public\nstatements or having to make changes to something they clearly want, I\nexpect them to redefine what \"real consensus\" means. I hope I'm wrong, but\nif I'm not ..... well, at least everyone will see what Gavin and I have\nbeen talking about for so many months.\n\nBut I'd rather the opcode is tweaked. There's real financial risks to a\nsoft fork.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/ea317e9d/attachment-0001.html\u003e"}