Matt Corallo [ARCHIVE] on Nostr: đź“… Original date posted:2021-02-22 đź“ť Original message:> On Feb 22, 2021, at ...
đź“… Original date posted:2021-02-22
đź“ť Original message:> On Feb 22, 2021, at 05:16, Anthony Towns <aj at erisian.com.au> wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
>> More importantly, nodes on both sides of the fork need to find each other.
>
> (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 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 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.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210222/08d2cbe2/attachment.html>;
đź“ť Original message:> On Feb 22, 2021, at 05:16, Anthony Towns <aj at erisian.com.au> wrote:
>
> If a lockinontimeout=true node is requesting compact blocks from a
> lockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,
> I think that could result in a ban.
>
>> More importantly, nodes on both sides of the fork need to find each other.
>
> (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 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 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.
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210222/08d2cbe2/attachment.html>;