Es scheint keinen überwältigenden Konsens über den Lockinontimeout (LOT)-Parameter für den Taproot BIP 8-Aktivierungsmechanismus zu geben. Ich weiß, dass einige stark dagegen argumentieren würden, aber könnte Bitcoin Core eine Version veröffentlichen, in der Benutzer gezwungen sind , zu wählen, ob sie LOT auf wahr oder falsch setzen, bevor sie die Software ausführen? Ist das technisch machbar?
Matt Corallo und ZmnSCPxj beantworteten dies auf der Bitcoin-Dev-Mailingliste.
Matt Corallo erklärte :
Bitcoin Core verfügt nicht über eine Infrastruktur, um das Wechseln von Konsensregeln mit demselben Datenverzeichnis zu handhaben – nach dem Laufen mit uasf=true für einige Zeit werden gültige Blöcke als ungültig markiert, und es müssten zusätzliche Entwicklungen durchgeführt werden, um das Zurückwechseln zu uasf=false zu ermöglichen. Dies ist ein komplexer, kritischer Code, um ihn richtig zu machen, und die erforderlichen Überprüfungs- und Testzyklen scheinen sich nicht zu lohnen.
Stattdessen wäre die einzig praktische Möglichkeit, eine solche Option zu versenden, sie als separate Kette zu behandeln (so wie Regtest, Testnet und Signet behandelt werden), einschließlich eines eigenen separaten Datenverzeichnisses und dergleichen.
ZmnSCPxj hinzugefügt :
Ohne irgendetwas anderes zu implizieren, kann dies von einem Benutzer umgangen werden, der zwei
datadirs verwaltet und zwei Clients betreibt. Dies hätte einen "externen" Client, der LOT=X ausführt (wobei X das ist, was der Benutzer bevorzugt) und einen "internen" Client, der höchstens 0.21.0 ist, was keine LOT-Regeln auferlegt. Der interne Client verwendet dannconnect=Anweisung, sich lokal mit dem externen Client zu verbinden, und stellt nur eine Verbindung zu diesem Client her und verwendet ihn als Firewall. Der externe Client kann beschnitten ausgeführt werden, um die Nutzung von Festplattenspeicherressourcen zu reduzieren (der interne Client kann unbeschnitten bleiben, wenn dies vom Benutzer benötigt wird, z. B. für die LN-Implementierung, die nach beliebigen Kurzkanal-IDs suchen muss). Die Bandbreitennutzung sollte gleich sein, da der interne Client nur eine Verbindung zum externen Client herstellt und das Betriebssystem diesen Fall optimieren sollte. Die CPU-Auslastung wird jedoch verdoppelt. (Die allgemeine Idee kam von gmax, nur um klar zu sein, obwohl die folgende Verwendung von mir stammt)Dann kann der Benutzer LOT=C oder LOT=!C (wobei C das ist, was Bitcoin Core letztendlich mitliefert) auf dem externen Client basierend auf den Benutzereinstellungen auswählen.
Wenn Taproot nicht MASF-aktiviert ist und später LOT=!U dominiert (wobei U das ist, wofür sich der Benutzer entschieden hat), kann der Benutzer entscheiden, einfach den externen Knoten zu zerstören und den internen Knoten direkt mit dem Netzwerk zu verbinden (optional ein Upgrade der interner Knoten zu LOT=!U), um "ihre Meinung im Hinblick auf die Wirtschaft zu ändern". Der interne Knoten folgt dann der dominanten Kette.