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 8D1ECC0001 for ; Mon, 22 Feb 2021 14:00:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 7771E87174 for ; Mon, 22 Feb 2021 14:00:33 +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 AHmge0Y1+80Q for ; Mon, 22 Feb 2021 14:00:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id A472587038 for ; Mon, 22 Feb 2021 14:00:32 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 02B1A4AEF48; Mon, 22 Feb 2021 14:00:29 +0000 (UTC) X-DKIM-Note: Keys used to sign are likely public at https://as397444.net/dkim/ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mattcorallo.com; s=1614001264; t=1614002430; bh=m3iS+SP3gIfVtXTecQyGqFqS5irqbp/R/xuYvsTiowE=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=NRDJ2y74PAUdRtJQKKJDJTGJvIQVZ2UiwJ1jNqT68nwkCFAd9BQM9uQ3iIqh6JA9B kZ/CP9PzIOoZRCHkDcjvR3lUrafCQ09fRixt2z0xpAAuzw1BpkjHzlfnDEHhE3dTbQ N8iCw5fNLsSyHefUJzPB4d/PeWPWFdY+KYV52mTdnu8+tJtqzWrbGCtZqWExVaHW6t xUocrSYJBytV8y2zAMJQ7PcHAIjwVzhYGbY8M9VKmd0zaauc0X6kewSE+6dc1EgfAP M/KEPauPiKiCey2FyqHBAXq/VeZI5fpJuS/DFAnWZ60aSy5uUDYofURHtyNgM+JWFd UJ6Iu971VCgPw== Content-Type: multipart/alternative; boundary=Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63 Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Date: Mon, 22 Feb 2021 09:00:29 -0500 Message-Id: <7B0D8EE4-19D9-4686-906C-F762F29E74D4@mattcorallo.com> References: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au> In-Reply-To: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au> To: Anthony Towns 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 14:00:33 -0000 --Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Feb 22, 2021, at 05:16, Anthony Towns wrote: >=20 > =EF=BB=BFIf a lockinontimeout=3Dtrue node is requesting compact blocks fro= m a > lockinontimeout=3Dfalse node during a chainsplit in the MUST_SIGNAL phase,= > I think that could result in a ban. >=20 >> More importantly, nodes on both sides of the fork need to find each other= .=20 >=20 > (If there was going to be an ongoing fork there'd be bigger things to > worry about...) I think it should be clear that a UASF-style command line option to allow co= nsensus rule changes in the node in the short term, immediately before a for= k carries some risk of a fork, even if I agree it may not persist over month= s. We can=E2=80=99t simply ignore that. > 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=3Dtrue 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 mate= rial technical complexity hiding behind a =E2=80=9Cchange the consensus rul= es=E2=80=9C option. Given it=E2=80=99s not a critical feature by any means, p= utting resources into fixing these issues probably isn=E2=80=99t worth it. Matt= --Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Feb 22, 2021, at 05:16, Anthony Towns <= aj@erisian.com.au> wrote:

=EF=BB=BFIf a lockinontimeout=3Dtrue node is req= uesting compact blocks from a
lockinontimeout=3Dfalse node d= uring a chainsplit in the MUST_SIGNAL phase,
I think that co= uld result in a ban.

More importantly, nodes on both sides of the fork need to find each othe= r.

(If there was going to be a= n ongoing fork there'd be bigger things to
worry about...)

I think it should be clear t= hat a UASF-style command line option to allow consensus rule changes in the n= ode 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=E2=80=99t simply ig= nore that.

I think= the important specific case of this is something like "if a chainwhere taproot is impossible to activate is temporarily the most work,=
miners with lockinontimeout=3Dtrue need to be well connecte= d so they don't
end up competing with each other while they'= re catching back up".

Betwe= en this and your above point, I think we probably agree - there is material &= nbsp;technical complexity hiding behind a =E2=80=9Cchange the consensus rule= s=E2=80=9C option. Given it=E2=80=99s not a critical feature by any means, p= utting resources into fixing these issues probably isn=E2=80=99t worth it.

Matt
= --Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63--