{"type":"rich","version":"1.0","author_name":"npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","author_url":"https://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-22\n📝 Original message:On Mon, Feb 22, 2021 at 01:44:55AM -0500, Matt Corallo wrote:\n\u003e A node feeding you invalid headers (used to be) cause for a ban [...]\n\nHeaders that are invalid due to MUST_SIGNAL rules are marked as\nBLOCK_RECENT_CONSENSUS_CHANGE so don't directly result in a ban. If you're\ndoing headers-first relay, I think that will also prevent hitting the\nBLOCK_MISSING_PREV case, which would result in a ban.\n\nIf a lockinontimeout=true node is requesting compact blocks from a\nlockinontimeout=false node during a chainsplit in the MUST_SIGNAL phase,\nI think that could result in a ban.\n\n\u003e More importantly, nodes on both sides of the fork need to find each other. \n\n(If there was going to be an ongoing fork there'd be bigger things to\nworry about...)\n\nI think the important specific case of this is something like \"if a chain\nwhere taproot is impossible to activate is temporarily the most work,\nminers with lockinontimeout=true need to be well connected so they don't\nend up competing with each other while they're catching back up\".\n\nActually, that same requirement might be more practically for a signet\nfeature we were thinking about -- namely having \"optional reorgs\", ie\nevery now and then we'd mine 1-6 blocks and then reorg them out; but\nalso flag the soon-to-be-stale blocks in some way so that if you didn't\nwant to have to deal with reorgs you could easily ignore them. Having\nit be possible for the \"I want to see reorgs!\" nodes to be able to find\neach other seems like it might be a similar problem (avoiding having the\n\"don't-want-reorgs\" nodes ban the \"want-reorgs\" nodes too perhaps).\n\nCheers,\naj"}