rich1.0npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlphahttps://nostr.ae/npub1t5mnh3ztdjmffuykas2g2ulx5y3tcv69t0qk0t0r4e3azxy3shfq0vlphanjumphttps://nostr.ae📅 Original date posted:2021-02-20 📝 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. Cheers Ariel Lorenzo-Luaces ⁣​ On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: >Good morning list, > >> It was pointed out to me that this discussion is largely moot as the >software complexity for Bitcoin Core to ship an >> option like this is likely not practical/what people would wish to >see. >> >> Bitcoin Core does not have infrastructure to handle switching >consensus rules with the same datadir - after running with >> uasf=true for some time, valid blocks will be marked as invalid, and >additional development would need to occur to >> enable switching back to uasf=false. This is complex, critical code >to get right, and the review and testing cycles >> needed seem to be not worth it. > >Without implying anything else, this can be worked around by a user >maintaining two `datadir`s and running two clients. >This would have an "external" client running an LOT=X (where X is >whatever the user prefers) and an "internal" client that is at most >0.21.0, which will not impose any LOT rules. >The internal client then uses `connect=` directive to connect locally >to the external client and connects only to that client, using it as a >firewall. >The external client can be run pruned in order to reduce diskspace >resource usage (the internal client can remain unpruned if that is >needed by the user, e.g. for LN implementation sthat need to look up >arbitrary short-channel-ids). >Bandwidth usage should be same since the internal client only connects >to the external client and the OS should optimize that case. >CPU usage is doubled, though. > >(the general idea came from gmax, just to be clear, though the below >use is from me) > >Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin >Core ultimately ships with) on the external client based on the user >preferences. > >If Taproot is not MASF-activated and LOT=!U is what dominates later >(where U is whatever the user decided on), the user can decide to just >destroy the external node and connect the internal node directly to the >network (optionally upgrading the internal node to LOT=!U) as a way to >"change their mind in view of the economy". >The internal node will then follow the dominant chain. > > >Regards, >ZmnSCPxj > >> >> Instead, the only practical way to ship such an option would be to >treat it as a separate chain (the same way regtest, >> testnet, and signet are treated), including its own separate datadir >and the like. >> >> Matt >> >> On 2/19/21 09:13, Matt Corallo via bitcoin-dev wrote: >> >> > (Also in response to ZMN...) >> > 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. >> > 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). >> > Matt >> > >> > > On Feb 19, 2021, at 07:08, Adam Back adam at cypherspace.org wrote: >> > > >> > > > would dev consensus around releasing LOT=false be considered as >"developers forcing their views on users"? >> > > >> > > given there are clearly people of both views, or for now don't >care >> > > but might later, it would minimally be friendly and useful if >> > > bitcoin-core has a LOT=true option - and that IMO goes some way >to >> > > avoid the assumptive control via defaults. >> > >> > > Otherwise it could be read as saying "developers on average >> > > disapprove, but if you, the market disagree, go figure it out for >> > > yourself" which is not a good message for being defensive and >avoiding >> > > mis-interpretation of code repositories or shipped defaults as >> > > "control". >> > >> > bitcoin-dev mailing list >> > bitcoin-dev at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev at lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210220/05495dc3/attachment.html>