{"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 09:00:29AM -0500, Matt Corallo wrote:\n\u003e I think it should be clear that a UASF-style command line option to allow\n\u003e consensus rule changes in the node in the short term, immediately before a fork\n\u003e carries some risk of a fork, even if I agree it may not persist over months. We\n\u003e can’t simply ignore that.\n\nI don't think a \"-set-bip8-lockinontimeout=taproot\" option on its own\nwould be very safe -- if we were sure it was safe, because we were sure\nthat everyone would eventually set lockinontimeout=true, then we would\nset lockinontimeout=true from day one and not need an option. I haven't\nseen/had any good ideas on how to make the option safe, or at least make\nit obvious that you shouldn't be setting it if you don't really\nunderstand what you're getting yourself into. [0]\n\nAnd that's even if you assume that the code was perfectly capable of\nhandling forks in some theoretically optimal way.\n\nSo at least for the time being, I don't think a config param / command\nline option is a good idea for bip8. IMHO, YMMV, IANABDFL etc.\n\n\u003e     I think the important specific case of this is something like \"if a chain\n\u003e     where taproot is impossible to activate is temporarily the most work,\n\u003e     miners with lockinontimeout=true need to be well connected so they don't\n\u003e     end up competing with each other while they're catching back up\".\n\u003e Between this and your above point, I think we probably agree - there is\n\u003e material  technical complexity hiding behind a “change the consensus rules“\n\u003e option. Given it’s not a critical feature by any means, putting resources into\n\u003e fixing these issues probably isn’t worth it.\n\nFor reference, the \"preferentially peer with other UASF nodes\" PR for\nthe BIP148 client was\n\n  https://github.com/UASF/bitcoin/pull/24\n\nList discussion was at\n\n  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014618.html\n\nI think I'll add playing around with that and reorgs on a signet to my\ntodo list to see how it goes in cases other than ones that are (hopefully)\nvanishingly unlikely to ever happen in practice.\n\nCheers,\naj\n\n[0] In some sense, this is exactly the opposite sentiment compared to\n    earonesty's comment:\n\n    https://github.com/bitcoin/bitcoin/pull/10900#issuecomment-317333312\n\n    I mean, I guess could solve the unsafe-now-but-maybe-safe-later\n    problem generally with a signature:\n\n      -authorise-dangerous-options-key=XXXX\n      -lockinontimeout=taproot:YYYY\n\n    where YYYY is a signature of \"dangerous:lockinontimeout=taproot\" or\n    similar by the key XXXX, and XXXX defaults to some (multisig?) key\n    controlled by some bitcoin people, who'll only sign that when\n    there's clear evidence that it will be reasonably safe, and maybe to\n    \"cert-transparency\" or something as well. So that allows having an\n    option become available by publishing a signature, without having\n    to recompile the code. And it could still be overriden by people who\n    know what they're doing if the default key owners are being weird. And\n    maybe the \"dangerous\" part is enough to prevent people from randomly\n    cut-and-pasting it from a website into their bitcoin.conf.\n\n    I dunno. No bad ideas when brainstorming..."}