(Habe dieses X-Artikel-Ding noch nie ausprobiert)
Lass mich zunächst sagen, dass ich weder für BIP110 noch dagegen bin. Wenn es tatsächlich als etwas Erfolg hat, das echten Konsens im Netzwerk erlangt und von einer Mehrheit des Netzwerks durchgesetzt wird … cool. Wenn ja, dann machen wir mit, weil das Netzwerk gesprochen und es akzeptiert hat, und alle Knoten, einschließlich der Nicht-BIP110-Knoten, werden mitgezogen.
Leider ist das für Befürworter des Vorschlags nach jeder messbaren Metrik derzeit einfach nicht der Fall, und es scheint auch keine Entwicklung zu geben, die darauf hindeutet, dass sich das ändern wird.
Es gab viele irreführende Informationen zu dieser ganzen Sache, besonders im Kontext des Minings. Ein paar kurze Kernpunkte, um kurz auf einige Übertreibungen von Befürwortern zu entgegnen:
- BIP110 ist NICHT unvermeidlich. Es KANN scheitern.
- BIP110 kann und wird bei einer Minderheiten-Hashrate-Situation eine Kettenaufspaltung/-gabelung verursachen.
- BIP110 ist NICHT ohne Risiko für Miner, die es übernehmen.
- Miner, die BIP110 nicht unterstützen, minen nicht plötzlich „ungültige“ Blöcke, nur weil ein noch nicht verabschiedeter Vorschlag existiert.
- Du bist kein schlechter Mensch oder böse, nur weil du BIP110 nicht magst oder unterstützt.
(Die Tatsache, dass ich das Bedürfnis habe, diesen letzten Teil zu erwähnen, ist eigentlich irgendwie traurig…)
Ich wollte einen langen Beitrag schreiben, um Miner über Dinge zu informieren, die sie im Auge behalten sollten, während sich das alles abspielt … bevor ich feststellte, dass ich das bereits vor Monaten in einem von mir verfassten Dokument getan hatte, das ich als Miner-Aufklärungsstück bei OCEAN veröffentlichen wollte. Leider wurde es nie veröffentlicht. Also habe ich es aktualisiert, und nun, hier ist es:
https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
Nochmal, bedenke, dass dies vor Monaten geschrieben wurde, mit dem Ziel, so neutral wie möglich zu sein, um es als Unternehmensbeitrag akzeptabel zu machen. Dieser Versuch ist gescheitert, also veröffentliche ich es heute stattdessen als persönliches Dokument.
Als Miner, der wichtige Entscheidungen über deinen Betrieb trifft, musst du dir all dessen bewusst sein, ohne die Beschönigungen und offen gesagt irreführenden Informationen, die von einigen BIP110-Befürwortern kommen. Du musst wachsam sein und entscheiden, was für dich richtig ist. Während es sicherlich auch irreführende Informationen von der Gegenseite gibt, ist nichts, was ich gesehen habe, annähernd so krass wie die extrem verfrühten Siegesbekundungen und die damit einhergehende Übertreibung von Seiten der BIP110-Befürworter.
Um mein Dokument etwas zusammenzufassen, mein persönlicher Vorschlag an Miner ist dieser:
- Signaliere, wenn du BIP110 unterstützt
- Signaliere nicht, wenn du BIP110 nicht unterstützt oder es dir egal ist
- Überwache in jedem Fall das Netzwerk um/um/vor Block 961.632.
- Wenn du weiterhin nicht-signalisierende Blöcke von großen Pools siehst, kannst du ziemlich sicher sein, dass sie nicht plötzlich beschließen, Millionen von Dollar an Einnahmen wegzuwerfen, um einen Rückzieher zu machen und für BIP110 zu signalisieren.
- Falls sie doch anfangen sollten, für BIP110 zu signalisieren, solltest du das beobachten und erwägen, bei Bedarf zu wechseln, um auf der schwersten Kette zu bleiben.
Der entscheidende Punkt ist, dass realistisch gesehen nur eine Seite gewinnen kann. Entweder BIP110 hat Erfolg und Miner, die nicht auf der BIP110-Seite stehen, scheitern, oder BIP110 scheitert und Miner auf der Nicht-BIP110-Seite haben Erfolg.
Weiter geht's, lass uns in einen kleinen Teil meiner Begründung eintauchen.
🟠KURZFAKT: Zwischen 7 und 15 % der Bitcoin-Knoten signalisieren Unterstützung für BIP110.
Je nachdem, welchen zentralisierten Crawler du betrachtest … keine Möglichkeit, es genau zu wissen. Mein persönlicher privater Crawler setzt diese Zahl viel niedriger an, aber das ist eine Diskussion für einen anderen Tag. Es genügt zu sagen, dass ich denke, es ist logisch und richtig zu sagen, dass selbst 15 % keine Mehrheit sind.
„Aber Jason! UASF hat Segwit mit weniger Knoten aktiviert!“
Ja, weil viele Miner, Händler, Nutzer usw. Segwit tatsächlich wollten. Es gab enormes wirtschaftliches und gemeinschaftliches Gewicht dahinter. Ohne die ganze Sache noch einmal aufzurollen (es gibt viele Ressourcen zu diesem Thema von vor BIP110, die eine Lektüre wert sind), genügt es zu sagen, dass BIP110 und Segwit-Aktivierungen nicht ganz vergleichbar sind, wie viele bereits angemerkt haben. Segwit zum Beispiel ging in sein UASF-Territorium, als bereits etwa ein Drittel der Netzwerk-Hashrate Unterstützung signalisierte. Mit einer solchen Unterstützung ergab die UASF zur Unterstützung der MASF über den Kipppunkt hinweg viel Sinn.
Es ergibt hier für BIP110 keinen Sinn.
🟠KURZFAKT: 0,6 % der Blöcke der letzten 60 Tage haben Unterstützung für BIP110 signalisiert.
Ein ziemlich starken Kontrast selbst zur niedrigen Basisunterstützung von Segwit. Ja, ich weiß, dass es in den letzten Wochen etwas zugenommen hat, aber keine neuen Teilnehmer. Nur deutlicher gemietete Hashrate von einem der gleichen kleinen Befürworter.
Etwas, das man bedenken sollte, ist, dass das Minen von BIP110-signalisierenden Blöcken über DATUM auf OCEAN bis zum Fork-Punkt bei Block 961.632 praktisch kein Risiko für den Miner birgt. Die Kosten sind vernachlässigbar, da du effektiv garantierst, die Mietkosten usw. wieder hereinzuholen.
Es ist großartig, dass diese Möglichkeit existiert, und ich möchte es nicht anders haben … aber nur etwas, das man bedenken sollte, wenn man die Signalisierung solcher Blöcke im großen Ganzen aus einer Risiko-/Belohnungs-/Geld-auf-dem-Tisch-Perspektive abwägt.
„Aber Jason! Miner haben keinen Anreiz, bis zur letzten Minute zu signalisieren!“
Ich sehe auch keine Beweise, die darauf hindeuten, dass dies der Fall sein könnte. Subjektiv widerspreche ich der Prämisse, da es nicht im besten Interesse eines Mining-Pools ist, das Netzwerk auf diese Weise zu destabilisieren. Ein Grund für frühe Signalisierungs- und Sperrfristen ist, Upgrades reibungslos zu koordinieren. Bis zur letzten Minute zu warten, macht diesen Vorteil zunichte. Ich sehe keine überzeugende Begründung oder Vorteil darin.
Weiter in diesem Zusammenhang: Als Teil meines persönlichen Knotenüberwachungs-Setups überwache ich spezifisch Knoten, die bekanntermaßen zu verschiedenen Entitäten gehören, wie anderen Mining-Pools, Börsen, großen Lightning-Knoten, Händlern usw. Eine überwältigende Mehrheit davon wird mit ausdrücklicher Erlaubnis und Bestätigung/Koordination überwacht.
🟠KURZFAKT: Alle großen Mining-Pools, die ich überwache, laufen derzeit auf einer Variante von Bitcoin Core v30 oder v31 (außer OCEAN).
Zur Erweiterung: Die meisten haben ihre Knoten seit der Verbreitung von BIP110s Veröffentlichung aktualisiert, sogar seit der Veröffentlichung von Knots 29.3. Zudem ist bekannt, dass viele Mining-Pools modifizierte Versionen ihrer Knotensoftware verwenden, um verschiedene Anforderungen ihrer spezifischen Infrastruktur zu erfüllen. Solche Änderungen müssten auf einen BIP110-kompatiblen Client portiert, getestet, bewertet und rechtzeitig bereitgestellt werden. Ich sehe derzeit keine Hinweise darauf, dass dies der Fall ist.
Soweit ich das beurteilen kann, sind die Pools sich bewusst, ignorieren es aber.
„Aber Jason! Miner bestimmen nicht den Konsens! Knoten tun das! Sonst streichen sie einfach die Halbierungen!“
Das ist eines der lustigsten und lächerlichsten Argumente, die ich von der Pro-BIP110-Gruppe gehört habe. Einen Konsenswechsel, der von Minern einseitig im Netzwerk durchgesetzt und von 100 % der bestehenden Knoten akzeptiert werden kann (ein Soft Fork), mit einem Hard Fork zu vergleichen, den kein bestehender Knoten akzeptieren wird … ist bestenfalls unaufrichtig.
Regeln zu verschärfen (wie BIP110): Soft Fork, kann von Minern durchgesetzt werden, wenn sie sich dafür entscheiden. Regeln zu lockern (wie das Absagen einer Halbierung): Hard Fork, kann von Minern nicht ohne effektiv 100 % Zustimmung des gesamten Netzwerks durchgesetzt werden …… was wahrscheinlich nicht passieren wird.
Die beiden zu vergleichen ist, einfach gesagt, einfach dumm.
„Aber Jason! Wenn du nicht auf die neuesten Konsensregeln aktualisierst, bist du unsicher! Du wirst Geld verlieren! Du wirst ungültige Blöcke minen! Du wirst [füge hier zusätzliche Übertreibung ein]!“
Das würde für einen Konsenswechsel gelten, der nun ja, Konsens hat. Während BIP110 einen tapferen Versuch unternommen hat, diesen Konsens zu erlangen, hat es noch keine messbare Mehrheit zu dem, was nun wohl die elfte Stunde ist. Weder bei Knoten, noch bei Hashrate, noch in den sozialen Schichten (consensus.health hat dort eine coole Visualisierung, wo du mich in der Mitte findest).
Falls BIP110 irgendwie 51 %+ der Netzwerk-Hashrate an/vor Block 961.632 erreicht … dann, okay. Es wird durchgesetzt, da als Soft Fork eine Mehrheit der Miner es einseitig durchsetzen kann, in Abwesenheit eines vollständig angenommenen URSF (effektiv ein Fehlbegriff, da dies irgendwie ein Hard Fork wäre).
„Aber Jason! Es kann keinen Konsens erlangen, indem es bereits Konsens hat! Du musst ihm eine Chance geben!“
Erstens … nein, muss ich nicht, obwohl ich es getan habe. Zweitens, es ist ein überstürzter Vorschlag, der nie die Zeit hatte, überhaupt zu versuchen, echten Konsens zu erlangen. Es sind 7 Monate seit der Veröffentlichung des ersten BIP110-Clients vergangen. Es sind noch etwa 3 Wochen bis zum Start der „obligatorischen“ Signalisierung (weniger, wenn du dies liest). 90 % der verfügbaren Zeit sind vergangen, ohne dass sich die allgemeine Stimmung bei irgendeinem relevanten Akteur geändert hat. Wenn es in den letzten 7 Monaten nicht ausreichend angenommen wurde, wird es das in den nächsten 3 Wochen wahrscheinlich auch nicht.
„Aber Jason! CSAM! CSAM! Pädophile! CSAM!“
Ich bin der Erste, der sagt, dass selbst ich das Risiko hier früh übertrieben habe, als Core seine OP_RETURN-Änderung vorschlug. Ich persönlich erwartete, dass etwas besonders Schlimmes fast sofort auf die Chain kommen würde, und nach meinem besten Wissen ist das noch nicht passiert. Könnte es immer noch passieren? Ja, nehme ich an.
Aber wenn man aus technischer Perspektive bedenkt, dass dasselbe zusammenhängende beliebige Daten Byte für Byte nachweislich in der aktuellen Chain oder der BIP-110-Chain gespeichert werden können, ohne große Probleme … dieses spezielle Argument für BIP-110 ist für mich an diesem Punkt ziemlich hinfällig.
Will ich CSAM in der Chain? Natürlich nicht. Bin ich ein Pädophiler, wenn ich BIP110 nicht unterstütze? Auch nicht.
...
Ich könnte noch weiter und weiter und weiter machen, aber ich höre hier auf. Ich habe genug Zeit damit verschwendet. Ich bin sicher, ich habe genug getan, um beide Seiten der BIP110-Debatte zu verärgern, da ich keine der beiden Positionen einnehme. Ich bin sicher, ich werde von allen Seiten Kritik einstecken müssen, nur weil ich es wage, meine Meinung dazu zu sagen.
Insgesamt denke ich, es war albern, ein reales Problem (die OP_RETURN-Standardänderung in Bitcoin Core) mit dem maximalen Anti-Spam-Manifest-basierten Soft-Fork-Vorschlag anzugehen … der nachweislich Spam, beliebige Daten usw. nicht stoppen kann. 🤦♂️ (Ja, ich weiß, Befürworter werden behaupten, es gehe nicht um Spam … und werden auch semantische Argumente bringen, dass es auch Daten stoppt … beides scheint nicht korrekt zu sein.)
Ich schließe mit dem Zugeständnis, dass ich falsch liegen könnte. Ich bin kein Nostradamus und kann das Ergebnis nicht mit 100%iger Sicherheit genau vorhersagen. Ich kann mich nur auf das verlassen, was die Daten mir sagen, und daher gebe ich BIP110s Erfolg eine Wahrscheinlichkeit von weniger als 5 % … und das halte ich für großzügig.
Du kannst meine Meinungen dazu annehmen, wie du möchtest, aber ich empfehle dir dringend, die tatsächlichen Datenpunkte nicht zu ignorieren, wachsam zu bleiben und das zu tun, was für dich und deine Mining-Einnahmen am besten ist. Lass dich von keiner Seite der Debatte manipulieren und triff deine eigenen Entscheidungen.
Hier ist ein Link zum selben Dokument wie oben, für den einfachen Zugriff: https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
