{"type":"rich","version":"1.0","author_name":"npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","author_url":"https://nostr.ae/npub1f2nxequ09nz44775vv6lkffq2plzqvrqramnk29eddmwcc9z7jys8ms289","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-04-21\n📝 Original message:Good day Michael,\n\n\u003e and discuss working on an additional release that if run may ultimately\nreject blocks that signal for CTV.\n\nThis seems silly to me.\n\nThe structure of CTV is imbuing an OP_NOP with script semantics. Resisting\nchanges that don't affect you is not consistent with the ideals of people\nbeing able to structure their own private agreements as they see fit...aka\nfreedom. It seems needlessly coercive to try and resist CTV in this way.\nCTV is ultimately an opt-in proposal. If you don't like the risk/benefit\nratio, you can simply not generate scripts that contain CTV checks.\nConservatism and apathy are something I can understand, but resisting CTV\nvia an escalating soft fork is not conservatism or apathy, it's fundamental\nopposition. What is it that you hope to accomplish by blocking others from\nusing a new opcode? According to your formal statement, you haven't really\nopposed CTV on fundamental grounds so much as vaguely questioning whether\nor not it is the \"best tool for the job\"...as if anyone really has the\ncapacity to judge that for a diverse group with varying interests and use\ncases that may differ substantially from their own.\n\nThere are really two ways to effectively resist this change: 1. reject all\nblocks during the lockin period, 2. reject all blocks that include OP_CTV\nin the script.\n\nRegardless of which method you choose, it is ultimately going to be a far\nmore forceful/invasive consensus change than CTV was in the first place. So\nhave fun trying to explain yourself out of that one. You've gone from\nsaying you won't NACK the proposal on its own to intentionally cause\nconsensus forks to block its enforcement. Did you change your mind or\nsomething?\n\n\u003e Hence it is prudent to prepare for an eventuality where the miner\nsignaling threshold might be reached but the community wants to prevent the\nattempted soft fork from activating. (I personally don't think a 90 percent\nminer signaling threshold will be reached but I wouldn't want to bet\nBitcoin's future on it.)\n\nMaking the statement that \"the community doesn't want this to activate\" as\nif it's some kind of foregone conclusion is a pretty bold claim. I think\nyou'll be surprised at how broad support actually is. To contrast your\nsecond citation, here's the set of people who have endorsed the proposal,\nalong with a handful of people opposed (such as yourself):\nhttps://utxos.org/signals/. If you are aware of others who are opposed, it\nwould be worth your time to solicit a statement from them that can be put\non the signals page. Absent that, it seems appropriate to assume that the\noverwhelming majority of people who have opined on the subject are for it.\n\n\u003e But as always with Jeremy caution and conservatism seems to be thrown out\nthe window and we have to react to that. It goes without saying that this\nis not how Bitcoin consensus changes should be attempted.\n\nWhat an unhinged take. The level of effort put into gathering consensus for\nCTV has set the bar higher than Taproot. Taproot didn't have the level of\noutreach effort that CTV does, and the complexity in taproot is\nsignificantly larger than for CTV. You didn't seem to have a problem\norganizing that activation process. That proposal was opened for public\ndiscussion in Jan'20, merged in Oct'20, and you were organizing activation\ndiscussions as early as Jan'21. The design of CTV has been *final* since\nFeb'20, a month after Taproot was opened for public discussion. There's a\nton of Proof-of-Concept code that has been written to test out use cases\nfor CTV, but for Taproot it still doesn't look like we'll have MuSig for a\nwhile longer (I heard a year, but someone can correct me on that if I'm\nwrong), and wallet support for Taproot wasn't fleshed out until after\nactivation. Characterizing Jeremy's efforts as throwing caution and\nconservatism out the window is hypocritical at best and malicious at worst.\n\nFinally, I think it is worth stating that if Bitcoin adopts a culture where\na willfully ignorant set of people can block changes that have no impact on\nthem, despite a large constituency wanting those changes, then Bitcoin kind\nof deserves the slow deterioration that will result from that. I don't\nreally find that future appealing and so I think that trying to find ways\nto activate non-invasive changes should be everyone's goal, *even if* they\npersonally may not have an immediate use case, or have a slight preference\nfor alternate solutions. The exception to this is any introduction of\nsystemic risk. Not all soft-forks are equal, and therefore the\nmeta-consensus requirements for getting them activated should vary based on\nhow broadly consequential the change is.\n\nFeel free to resist this if you want. In some sense that's what the Speedy\nTrial procedure is for. However, I think your case would be more compelling\nif you actually had some sort of affirmative argument for why CTV induces\nsystemic risk to non-users of the opcode. Expressing uncertainty over\nwhether it is the globally optimal solution (to a problem that cannot be\nglobally defined due to diverse interests) is not persuasive to me and many\nothers in the community.\n\nKeagan\n\nOn Thu, Apr 21, 2022 at 12:16 PM Michael Folkson via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Ok so we've had to scramble a bit as I don't think anyone except perhaps\n\u003e Jeremy thought that there would be a Speedy Trial signaling period for a\n\u003e CTV soft fork planned to start on May 5th [1]. That is two weeks away.\n\u003e\n\u003e (I have to take what he says at face value. I can understand why one would\n\u003e be skeptical.)\n\u003e\n\u003e Understandably this has angered and surprised a few people including some\n\u003e of those who have voiced opposition to a CTV soft fork activation being\n\u003e attempted in the first place [2].\n\u003e\n\u003e As I've said in a previous post [3] the Bitcoin Core 23.0 release\n\u003e candidate (and older versions) does not include any CTV code or CTV\n\u003e activation code. If a miner runs Bitcoin Core 23.0 out the box it will not\n\u003e signal for CTV. If by some chance CTV was to activate through some other\n\u003e software release Bitcoin Core releases would not apply CTV rules but they\n\u003e also wouldn't reject blocks that apply CTV rules. Hence it is prudent to\n\u003e prepare for an eventuality where the miner signaling threshold might be\n\u003e reached but the community wants to prevent the attempted soft fork from\n\u003e activating. (I personally don't think a 90 percent miner signaling\n\u003e threshold will be reached but I wouldn't want to bet Bitcoin's future on\n\u003e it.)\n\u003e\n\u003e I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but\n\u003e I'm open to better names. I certainly don't want to discourage those who\n\u003e dislike or oppose UASFs from contributing to this effort and potentially\n\u003e ultimately running a URSF release. If you don't want this rushed CTV soft\n\u003e fork to activate we are all on the same side whatever we call it.\n\u003e\n\u003e For now I've set up a ##ursf channel on Libera IRC to monitor developments\n\u003e and discuss working on an additional release that if run may ultimately\n\u003e reject blocks that signal for CTV.\n\u003e\n\u003e The intention of this would be to provide additional direction and\n\u003e incentive to miners that the community does not want this soft fork to be\n\u003e activated. To repeat running a Bitcoin Core release will not signal for a\n\u003e CTV soft fork out the box. If a miner runs a Bitcoin Core release it will\n\u003e not signal for CTV.\n\u003e\n\u003e Apologies that this is rushed. But as always with Jeremy caution and\n\u003e conservatism seems to be thrown out the window and we have to react to\n\u003e that. It goes without saying that this is not how Bitcoin consensus changes\n\u003e should be attempted.\n\u003e\n\u003e [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/\n\u003e [2]:\n\u003e https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718\n\u003e [3]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html\n\u003e\n\u003e --\n\u003e Michael Folkson\n\u003e Email: michaelfolkson at protonmail.com\n\u003e Keybase: michaelfolkson\n\u003e PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220421/9b2b5a9c/attachment-0001.html\u003e"}