From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id C2411C0001 for ; Mon, 22 Feb 2021 16:27:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id A89338720E for ; Mon, 22 Feb 2021 16:27:53 +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 kbN9lMa0d49d for ; Mon, 22 Feb 2021 16:27:52 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by hemlock.osuosl.org (Postfix) with ESMTPS id AB8EE871EF for ; Mon, 22 Feb 2021 16:27:52 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1lEE3m-00040y-Nb; Tue, 23 Feb 2021 02:27:48 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Tue, 23 Feb 2021 02:27:40 +1000 Date: Tue, 23 Feb 2021 02:27:40 +1000 From: Anthony Towns To: Matt Corallo Message-ID: <20210222162740.mif2uygjszupizqc@erisian.com.au> References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au> <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com> User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score-int: -18 X-Spam-Bar: - 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: Mon, 22 Feb 2021 16:27:53 -0000 On Mon, Feb 22, 2021 at 09:00:29AM -0500, Matt Corallo wrote: > 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. I don't think a "-set-bip8-lockinontimeout=taproot" option on its own would be very safe -- if we were sure it was safe, because we were sure that everyone would eventually set lockinontimeout=true, then we would set lockinontimeout=true from day one and not need an option. I haven't seen/had any good ideas on how to make the option safe, or at least make it obvious that you shouldn't be setting it if you don't really understand what you're getting yourself into. [0] And that's even if you assume that the code was perfectly capable of handling forks in some theoretically optimal way. So at least for the time being, I don't think a config param / command line option is a good idea for bip8. IMHO, YMMV, IANABDFL etc. > I think the important specific case of this is something like "if a chain > where taproot is impossible to activate is temporarily the most work, > miners with lockinontimeout=true need to be well connected so they don't > end up competing with each other while they're catching back up". > 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. For reference, the "preferentially peer with other UASF nodes" PR for the BIP148 client was https://github.com/UASF/bitcoin/pull/24 List discussion was at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html I think I'll add playing around with that and reorgs on a signet to my todo list to see how it goes in cases other than ones that are (hopefully) vanishingly unlikely to ever happen in practice. Cheers, aj [0] In some sense, this is exactly the opposite sentiment compared to earonesty's comment: https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312 I mean, I guess could solve the unsafe-now-but-maybe-safe-later problem generally with a signature: -authorise-dangerous-options-key=XXXX -lockinontimeout=taproot:YYYY where YYYY is a signature of "dangerous:lockinontimeout=taproot" or similar by the key XXXX, and XXXX defaults to some (multisig?) key controlled by some bitcoin people, who'll only sign that when there's clear evidence that it will be reasonably safe, and maybe to "cert-transparency" or something as well. So that allows having an option become available by publishing a signature, without having to recompile the code. And it could still be overriden by people who know what they're doing if the default key owners are being weird. And maybe the "dangerous" part is enough to prevent people from randomly cut-and-pasting it from a website into their bitcoin.conf. I dunno. No bad ideas when brainstorming...