{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-22\n📝 Original message:Just to clarify, I'm not saying bitcoin core should maintain the\n\"oppose proposal\" part of the software. presumably people opposing the\nchange don't want much of the recent software changes anyway.\nBut perhaps it wouldn't be so bad, to oppose other proposals, perhaps.\nI don't expect anyone to want this, but if people want it I offer\nmyself to code it,\nI mean, just imagine that a day after publishing a bitcoin core\nrelease with activation software for taproot some one, let's say in\nNew York reach an Agreement to \"just use the same activation\nmechanism, but for our 32 mb hardfork, it's about time, now computers\nare 64 bits anyway\". How convenient would it be to just cancel that\nwith 2 lines in bitcoin core?\nNot that I think it will be necessary, but perhaps we want it just in case.\n\nOn Mon, Feb 22, 2021 at 5:31 PM Jorge Timón \u003cjtimon at jtimon.cc\u003e wrote:\n\u003e\n\u003e Sorry, I haven't read everything. I just want to say what I think is\n\u003e the best option and why.\n\u003e Let's say something like 2 years in which miners can signal activation\n\u003e after which, the MUST signal it for their blocks to be valid (I think\n\u003e this is LOT=true, but I don't remember what LOT stands for).\n\u003e Some may argue than it's easier to move from LOT=false to LOT=true\n\u003e than viceversa (I think I'm getting this right), but either way\n\u003e different clients could interpret things more differently more easily\n\u003e and, you know, that's really bad.\n\u003e If anyone is against the consensus change itself, what they should do\n\u003e is run a client in which the must is turned into a MUST NOT. Whenever\n\u003e miners signal activation, blocks aren't valid so that it doesn't\n\u003e happen.\n\u003e That way both sides can be cleanly separated and both communities\n\u003e (assuming there's a community of users opposing the change) can stick\n\u003e together with their own in the same chain. That is, having only 2\n\u003e chains in total if there are users opposing the change or only one if\n\u003e not, but never 2 chains for people who want the change or 2 chains for\n\u003e pople who don't want it.\n\u003e\n\u003e Just my two sats, please nobody ask me \"why would anyone oppose\n\u003e taproot?\" or anything similar. Because I'm trying to generalize here,\n\u003e if we're talking about activation, I think the specifics of the change\n\u003e are kind of irrelevant.\n\u003e\n\u003e Separately: thanks to everyone who worked on taproot.\n\u003e\n\u003e\n\u003e On Mon, Feb 22, 2021 at 3:00 PM Matt Corallo via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Feb 22, 2021, at 05:16, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e \u003e\n\u003e \u003e If a lockinontimeout=true node is requesting compact blocks from a\n\u003e \u003e lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,\n\u003e \u003e I think that could result in a ban.\n\u003e \u003e\n\u003e \u003e More importantly, nodes on both sides of the fork need to find each other.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e (If there was going to be an ongoing fork there'd be bigger things to\n\u003e \u003e worry about...)\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I think it should be clear that a UASF-style command line option to allow consensus rule changes in the node in the short term, immediately before a fork carries some risk of a fork, even if I agree it may not persist over months. We can’t simply ignore that.\n\u003e \u003e\n\u003e \u003e I think the important specific case of this is something like \"if a chain\n\u003e \u003e where taproot is impossible to activate is temporarily the most work,\n\u003e \u003e miners with lockinontimeout=true need to be well connected so they don't\n\u003e \u003e end up competing with each other while they're catching back up\".\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Between this and your above point, I think we probably agree - there is material  technical complexity hiding behind a “change the consensus rules“ option. Given it’s not a critical feature by any means, putting resources into fixing these issues probably isn’t worth it.\n\u003e \u003e\n\u003e \u003e Matt\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}