<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Feb 22, 2021, at 05:16, Anthony Towns <aj@erisian.com.au> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">I<span>f a lockinontimeout=true node is requesting compact blocks from a</span><br><span>lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,</span><br><span>I think that could result in a ban.</span><br><span></span><br><blockquote type="cite"><span>More importantly, nodes on both sides of the fork need to find each other. </span><br></blockquote><span></span><br><span>(If there was going to be an 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 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.</div><br><blockquote type="cite"><div dir="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=true need to be well connected 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>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.</div><div><br></div><div><font color="#5856d6"><span style="caret-color: rgb(88, 86, 214);">Matt</span></font></div></body></html>