{"type":"rich","version":"1.0","author_name":"npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlpha","author_url":"https://nostr.ae/npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlpha","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-20\n📝 Original message:What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some of the concerns of having to coordinate a UASF with an approaching deadline.\n\nCheers\nAriel Lorenzo-Luaces\n⁣​\n\nOn Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003eGood morning list,\n\u003e\n\u003e\u003e It was pointed out to me that this discussion is largely moot as the\n\u003esoftware complexity for Bitcoin Core to ship an\n\u003e\u003e option like this is likely not practical/what people would wish to\n\u003esee.\n\u003e\u003e\n\u003e\u003e Bitcoin Core does not have infrastructure to handle switching\n\u003econsensus rules with the same datadir - after running with\n\u003e\u003e uasf=true for some time, valid blocks will be marked as invalid, and\n\u003eadditional development would need to occur to\n\u003e\u003e enable switching back to uasf=false. This is complex, critical code\n\u003eto get right, and the review and testing cycles\n\u003e\u003e needed seem to be not worth it.\n\u003e\n\u003eWithout implying anything else, this can be worked around by a user\n\u003emaintaining two `datadir`s and running two clients.\n\u003eThis would have an \"external\" client running an LOT=X (where X is\n\u003ewhatever the user prefers) and an \"internal\" client that is at most\n\u003e0.21.0, which will not impose any LOT rules.\n\u003eThe internal client then uses `connect=` directive to connect locally\n\u003eto the external client and connects only to that client, using it as a\n\u003efirewall.\n\u003eThe external client can be run pruned in order to reduce diskspace\n\u003eresource usage (the internal client can remain unpruned if that is\n\u003eneeded by the user, e.g. for LN implementation sthat need to look up\n\u003earbitrary short-channel-ids).\n\u003eBandwidth usage should be same since the internal client only connects\n\u003eto the external client and the OS should optimize that case.\n\u003eCPU usage is doubled, though.\n\u003e\n\u003e(the general idea came from gmax, just to be clear, though the below\n\u003euse is from me)\n\u003e\n\u003eThen the user can select LOT=C or LOT=!C (where C is whatever Bitcoin\n\u003eCore ultimately ships with) on the external client based on the user\n\u003epreferences.\n\u003e\n\u003eIf Taproot is not MASF-activated and LOT=!U is what dominates later\n\u003e(where U is whatever the user decided on), the user can decide to just\n\u003edestroy the external node and connect the internal node directly to the\n\u003enetwork (optionally upgrading the internal node to LOT=!U) as a way to\n\u003e\"change their mind in view of the economy\".\n\u003eThe internal node will then follow the dominant chain.\n\u003e\n\u003e\n\u003eRegards,\n\u003eZmnSCPxj\n\u003e\n\u003e\u003e\n\u003e\u003e Instead, the only practical way to ship such an option would be to\n\u003etreat it as a separate chain (the same way regtest,\n\u003e\u003e testnet, and signet are treated), including its own separate datadir\n\u003eand the like.\n\u003e\u003e\n\u003e\u003e Matt\n\u003e\u003e\n\u003e\u003e On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote:\n\u003e\u003e\n\u003e\u003e \u003e (Also in response to ZMN...)\n\u003e\u003e \u003e Bitcoin Core has a long-standing policy of not shipping options\n\u003ewhich shoot yourself in the foot. I’d be very disappointed if that\n\u003echanged now. People are of course more than welcome to run such\n\u003esoftware themselves, but I anticipate the loud minority on Twitter and\n\u003ehere aren’t processing enough transactions or throwing enough financial\n\u003eweight behind their decision for them to do anything but just switch\n\u003eback if they find themselves on a chain with no blocks.\n\u003e\u003e \u003e There’s nothing we can (or should) do to prevent people from\n\u003ethreatening to (and possibly) forking themselves off of bitcoin, but\n\u003ethat doesn’t mean we should encourage it either. The work Bitcoin Core\n\u003emaintainers and developers do is to recommend courses of action which\n\u003ethey believe have reasonable levels of consensus and are technically\n\u003esound. Luckily, there’s strong historical precedent for people deciding\n\u003eto run other software around forks, so misinterpretation is not very\n\u003ecommon (just like there’s strong historical precedent for miners not\n\u003eunilaterally deciding forks in the case of Segwit).\n\u003e\u003e \u003e Matt\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e On Feb 19, 2021, at 07:08, Adam Back adam at cypherspace.org wrote:\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e \u003e would dev consensus around releasing LOT=false be considered as\n\u003e\"developers forcing their views on users\"?\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e given there are clearly people of both views, or for now don't\n\u003ecare\n\u003e\u003e \u003e \u003e but might later, it would minimally be friendly and useful if\n\u003e\u003e \u003e \u003e bitcoin-core has a LOT=true option - and that IMO goes some way\n\u003eto\n\u003e\u003e \u003e \u003e avoid the assumptive control via defaults.\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e Otherwise it could be read as saying \"developers on average\n\u003e\u003e \u003e \u003e disapprove, but if you, the market disagree, go figure it out for\n\u003e\u003e \u003e \u003e yourself\" which is not a good message for being defensive and\n\u003eavoiding\n\u003e\u003e \u003e \u003e mis-interpretation of code repositories or shipped defaults as\n\u003e\u003e \u003e \u003e \"control\".\n\u003e\u003e \u003e\n\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210220/05495dc3/attachment.html\u003e"}