Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3BB0FC0001 for ; Sat, 20 Feb 2021 02:55:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 2F9AB87520 for ; Sat, 20 Feb 2021 02:55:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vG322YNMxDvq for ; Sat, 20 Feb 2021 02:55:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by hemlock.osuosl.org (Postfix) with ESMTPS id E5950874F3 for ; Sat, 20 Feb 2021 02:55:22 +0000 (UTC) Date: Sat, 20 Feb 2021 02:55:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1613789719; bh=yaOS9tPwEFG4nd5LeHLvMCqS9SJHb9dMiDjVIJHF0YU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=VeOIhOkwunAN9f6VHyzTeBXS8en1rEQPHKOeFbqynbWwROECeMkonrcY/Delcf7oa S3mEVFPhwimCkE79oU5QN8Pm0b9jdgqq/cJRhv0re/QwBCJkhjjfi+Gzf7B6uhKxtB F7yJEZTjjPWqaZMu38y/tm4xROglpCOiquG5gv+4= To: Matt Corallo From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Michael Folkson , Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2021 02:55:25 -0000 Good morning list, > It was pointed out to me that this discussion is largely moot as the soft= ware 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 r= ules with the same datadir - after running with > uasf=3Dtrue for some time, valid blocks will be marked as invalid, and ad= ditional development would need to occur to > enable switching back to uasf=3Dfalse. 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 maintai= ning two `datadir`s and running two clients. This would have an "external" client running an LOT=3DX (where X is whateve= r 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=3D` directive to connect locally to = the external client and connects only to that client, using it as a firewal= l. 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 us= er, e.g. for LN implementation sthat need to look up arbitrary short-channe= l-ids). Bandwidth usage should be same since the internal client only connects to t= he 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=3DC or LOT=3D!C (where C is whatever Bitcoin C= ore ultimately ships with) on the external client based on the user prefere= nces. If Taproot is not MASF-activated and LOT=3D!U is what dominates later (wher= e U is whatever the user decided on), the user can decide to just destroy t= he external node and connect the internal node directly to the network (opt= ionally upgrading the internal node to LOT=3D!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 s= hoot yourself in the foot. I=E2=80=99d be very disappointed if that changed= now. People are of course more than welcome to run such software themselve= s, but I anticipate the loud minority on Twitter and here aren=E2=80=99t pr= ocessing enough transactions or throwing enough financial weight behind the= ir decision for them to do anything but just switch back if they find thems= elves on a chain with no blocks. > > There=E2=80=99s nothing we can (or should) do to prevent people from th= reatening to (and possibly) forking themselves off of bitcoin, but that doe= sn=E2=80=99t mean we should encourage it either. The work Bitcoin Core main= tainers and developers do is to recommend courses of action which they beli= eve have reasonable levels of consensus and are technically sound. Luckily,= there=E2=80=99s strong historical precedent for people deciding to run oth= er software around forks, so misinterpretation is not very common (just lik= e there=E2=80=99s strong historical precedent for miners not unilaterally d= eciding forks in the case of Segwit). > > Matt > > > > > On Feb 19, 2021, at 07:08, Adam Back adam@cypherspace.org wrote: > > > > > > > would dev consensus around releasing LOT=3Dfalse 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=3Dtrue 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 avoidin= g > > > mis-interpretation of code repositories or shipped defaults as > > > "control". > > > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev