1  Return-Path: <aj@erisian.com.au>
 2  Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 3   by lists.linuxfoundation.org (Postfix) with ESMTP id F2427C0001
 4   for <bitcoin-dev@lists.linuxfoundation.org>;
 5   Mon, 22 Feb 2021 10:16:44 +0000 (UTC)
 6  Received: from localhost (localhost [127.0.0.1])
 7   by smtp3.osuosl.org (Postfix) with ESMTP id D35526F54D
 8   for <bitcoin-dev@lists.linuxfoundation.org>;
 9   Mon, 22 Feb 2021 10:16:44 +0000 (UTC)
10  X-Virus-Scanned: amavisd-new at osuosl.org
11  Received: from smtp3.osuosl.org ([127.0.0.1])
12   by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
13   with ESMTP id RsarhTLbbeMz
14   for <bitcoin-dev@lists.linuxfoundation.org>;
15   Mon, 22 Feb 2021 10:16:43 +0000 (UTC)
16  X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
17  Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
18   by smtp3.osuosl.org (Postfix) with ESMTPS id B89866F52F
19   for <bitcoin-dev@lists.linuxfoundation.org>;
20   Mon, 22 Feb 2021 10:16:43 +0000 (UTC)
21  Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
22   by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
23   id 1lE8Gc-0003J2-3J; Mon, 22 Feb 2021 20:16:39 +1000
24  Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
25   Mon, 22 Feb 2021 20:16:32 +1000
26  Date: Mon, 22 Feb 2021 20:16:32 +1000
27  From: Anthony Towns <aj@erisian.com.au>
28  To: Matt Corallo <lf-lists@mattcorallo.com>
29  Message-ID: <20210222101632.j5udrgtj2aj5bw6q@erisian.com.au>
30  References: <20210222051624.6eklzfec2bf4lqdk@erisian.com.au>
31   <4FF38E1A-677B-478C-B32F-4640DF867810@mattcorallo.com>
32  MIME-Version: 1.0
33  Content-Type: text/plain; charset=us-ascii
34  Content-Disposition: inline
35  In-Reply-To: <4FF38E1A-677B-478C-B32F-4640DF867810@mattcorallo.com>
36  User-Agent: NeoMutt/20170113 (1.7.2)
37  X-Spam-Score-int: -18
38  X-Spam-Bar: -
39  Cc: Michael Folkson <michaelfolkson@gmail.com>,
40   Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
41  Subject: Re: [bitcoin-dev] Yesterday's Taproot activation meeting on
42   lockinontimeout (LOT)
43  X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
44  X-Mailman-Version: 2.1.15
45  Precedence: list
46  List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
47  List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
48   <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
49  List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
50  List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
51  List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
52  List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
53   <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
54  X-List-Received-Date: Mon, 22 Feb 2021 10:16:45 -0000
55  
56  On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:
57  > A node feeding you invalid headers (used to be) cause for a ban [...]
58  
59  Headers that are invalid due to MUST_SIGNAL rules are marked as
60  BLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're
61  doing headers-first relay, I think that will also prevent hitting the
62  BLOCK_MISSING_PREV case, which would result in a ban.
63  
64  If a lockinontimeout=true node is requesting compact blocks from a
65  lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
66  I think that could result in a ban.
67  
68  > More importantly, nodes on both sides of the fork need to find each other. 
69  
70  (If there was going to be an ongoing fork there'd be bigger things to
71  worry about...)
72  
73  I think the important specific case of this is something like "if a chain
74  where taproot is impossible to activate is temporarily the most work,
75  miners with lockinontimeout=true need to be well connected so they don't
76  end up competing with each other while they're catching back up".
77  
78  Actually, that same requirement might be more practically for a signet
79  feature we were thinking about -- namely having "optional reorgs", ie
80  every now and then we'd mine 1-6 blocks and then reorg them out; but
81  also flag the soon-to-be-stale blocks in some way so that if you didn't
82  want to have to deal with reorgs you could easily ignore them. Having
83  it be possible for the "I want to see reorgs!" nodes to be able to find
84  each other seems like it might be a similar problem (avoiding having the
85  "don't-want-reorgs" nodes ban the "want-reorgs" nodes too perhaps).
86  
87  Cheers,
88  aj
89  
90