diff options
| author | Matt Corallo <lf-lists@mattcorallo.com> | 2021-02-22 09:00:29 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-02-22 14:00:33 +0000 |
| commit | d1bc67e75c9422ecbdf48ca05e5f41c4b1e7d3f6 (patch) | |
| tree | d85439a3d496e842d152ee5b33704562049add92 | |
| parent | b51c120f5c7f81bcd5cd79462c322794be0d0ecc (diff) | |
| download | pi-bitcoindev-d1bc67e75c9422ecbdf48ca05e5f41c4b1e7d3f6.tar.gz pi-bitcoindev-d1bc67e75c9422ecbdf48ca05e5f41c4b1e7d3f6.zip | |
Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)
| -rw-r--r-- | 1b/23847804bc8bd721ce18e13d600e41db13cc13 | 135 |
1 files changed, 135 insertions, 0 deletions
diff --git a/1b/23847804bc8bd721ce18e13d600e41db13cc13 b/1b/23847804bc8bd721ce18e13d600e41db13cc13 new file mode 100644 index 000000000..e23acb032 --- /dev/null +++ b/1b/23847804bc8bd721ce18e13d600e41db13cc13 @@ -0,0 +1,135 @@ +Return-Path: <lf-lists@mattcorallo.com> +Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 8D1ECC0001 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <lf-lists@mattcorallo.com> +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 <aj@erisian.com.au> +Cc: Michael Folkson <michaelfolkson@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <aj@erisian.com.au> 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 + +<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D= +utf-8"></head><body dir=3D"auto"><div dir=3D"ltr"><br></div><div dir=3D"ltr"= +><br><blockquote type=3D"cite">On Feb 22, 2021, at 05:16, Anthony Towns <= +aj@erisian.com.au> wrote:<br><br></blockquote></div><blockquote type=3D"c= +ite"><div dir=3D"ltr">=EF=BB=BFI<span>f a lockinontimeout=3Dtrue node is req= +uesting compact blocks from a</span><br><span>lockinontimeout=3Dfalse node d= +uring a chainsplit in the MUST_SIGNAL phase,</span><br><span>I think that co= +uld result in a ban.</span><br><span></span><br><blockquote type=3D"cite"><s= +pan>More importantly, nodes on both sides of the fork need to find each othe= +r. </span><br></blockquote><span></span><br><span>(If there was going to be a= +n ongoing fork there'd be bigger things to</span><br><span>worry about...)</= +span><br></div></blockquote><div><br></div><div>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.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"><span>I think= + the important specific case of this is something like "if a chain</span><br= +><span>where taproot is impossible to activate is temporarily the most work,= +</span><br><span>miners with lockinontimeout=3Dtrue need to be well connecte= +d so they don't</span><br><span>end up competing with each other while they'= +re catching back up".</span><br></div></blockquote><div><br></div><div>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.</= +div><div><br></div><div><font color=3D"#5856d6"><span style=3D"caret-color: r= +gb(88, 86, 214);">Matt</span></font></div></body></html>= + +--Apple-Mail-371C8FCD-A111-4CD0-903C-82404B831E63-- + |