{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-02-22\n📝 Original message:Hmm, indeed, I may have missed that you can skip the headers issues by not persisting them, though there are other follow-on effects that are concerning and I think still make my point valid.\n\nA node feeding you invalid headers (used to be) cause for a ban - is that information still persisted? More importantly, nodes on both sides of the fork need to find each other. There’s not a great way to do that without forking the address database, DNS seeds and defining a new protocol magic.\n\nMatt\n\n\u003e On Feb 22, 2021, at 00:16, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e \n\u003e On Fri, Feb 19, 2021 at 12:48:00PM -0500, Matt Corallo via bitcoin-dev wrote:\n\u003e\u003e It was pointed out to me that this discussion is largely moot as the\n\u003e\u003e software complexity for Bitcoin Core to ship an option like this is likely\n\u003e\u003e not practical/what people would wish to see.\n\u003e\u003e Bitcoin Core does not have infrastructure to handle switching consensus\n\u003e\u003e rules with the same datadir - after running with uasf=true for some time,\n\u003e\u003e valid blocks will be marked as invalid, \n\u003e \n\u003e I don't think this is true? With the current proposed bip8 code,\n\u003e lockinontimeout=true will cause headers to be marked as invalid, and\n\u003e won't process the block further. If a node running lockinontimeout=true\n\u003e accepts the header, then it will apply the same consensus rules as a\n\u003e lockinontimeout=false node.\n\u003e \n\u003e I don't think an invalid header will be added to the block index at all,\n\u003e so a node restart should always cleanly allow it to be reconsidered.\n\u003e \n\u003e The test case in\n\u003e \n\u003e https://github.com/bitcoin/bitcoin/pull/19573/commits/bd8517135fc839c3332fea4d9c8373b94c8c9de8\n\u003e \n\u003e tests that a node that had rejected a chain due to lockinontimeout=true\n\u003e will reorg to that chain after being restarted as a byproduct of the way\n\u003e it tests different cases (the nodes set a new startheight, but retain\n\u003e their lockinontimeout settings).\n\u003e \n\u003e \n\u003e (I think with the current bip8 code, if you switch from\n\u003e lockinontimeout=false to lockinontimeout=true and the tip of the current\n\u003e most work chain is after the timeoutheight and did not lockin, then you\n\u003e will continue following that chain until a taproot-invalid transaction\n\u003e is inclued, rather than immediately reorging to a shorter chain that\n\u003e complies with the lockinontimeout=true rules)\n\u003e \n\u003e Cheers,\n\u003e aj\n\u003e"}