{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-19\n📝 Original message:It was pointed out to me that this discussion is largely moot as the software complexity for Bitcoin Core to ship an \noption like this is likely not practical/what people would wish to see.\n\nBitcoin Core does not have infrastructure to handle switching consensus rules with the same datadir - after running with \nuasf=true for some time, valid blocks will be marked as invalid, and additional development would need to occur to \nenable switching back to uasf=false. This is complex, critical code to get right, and the review and testing cycles \nneeded seem to be not worth it.\n\nInstead, the only practical way to ship such an option would be to treat it as a separate chain (the same way regtest, \ntestnet, and signet are treated), including its own separate datadir and the like.\n\nMatt\n\nOn 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:\n\u003e (Also in response to ZMN...)\n\u003e \n\u003e Bitcoin Core has a long-standing policy of not shipping options which shoot yourself in the foot. I’d be very disappointed if that changed now. People are of course more than welcome to run such software themselves, but I anticipate the loud minority on Twitter and here aren’t processing enough transactions or throwing enough financial weight behind their decision for them to do anything but just switch back if they find themselves on a chain with no blocks.\n\u003e \n\u003e There’s nothing we can (or should) do to prevent people from threatening to (and possibly) forking themselves off of bitcoin, but that doesn’t mean we should encourage it either. The work Bitcoin Core maintainers and developers do is to recommend courses of action which they believe have reasonable levels of consensus and are technically sound. Luckily, there’s strong historical precedent for people deciding to run other software around forks, so misinterpretation is not very common (just like there’s strong historical precedent for miners not unilaterally deciding forks in the case of Segwit).\n\u003e \n\u003e Matt\n\u003e \n\u003e\u003e On Feb 19, 2021, at 07:08, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e\u003e\u003e would dev consensus around releasing LOT=false be considered as \"developers forcing their views on users\"?\n\u003e\u003e\n\u003e\u003e given there are clearly people of both views, or for now don't care\n\u003e\u003e but might later, it would minimally be friendly and useful if\n\u003e\u003e bitcoin-core has a LOT=true option - and that IMO goes some way to\n\u003e\u003e avoid the assumptive control via defaults.\n\u003e \n\u003e\u003e Otherwise it could be read as saying \"developers on average\n\u003e\u003e disapprove, but if you, the market disagree, go figure it out for\n\u003e\u003e yourself\" which is not a good message for being defensive and avoiding\n\u003e\u003e mis-interpretation of code repositories or shipped defaults as\n\u003e\u003e \"control\".\n\u003e \n\u003e \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"}