Kann Segregated Witness in einer Emergent Consensus-Umgebung funktionieren?

Gleich wie Betreff. Ich fand es schwierig, eine Diskussion über die aktuelle Implementierung und Theorie des Emergent Consensus zu finden, aber ich habe Vorbehalte gesehen.

Wirkt es sich nachteilig auf die Realisierbarkeit der aktuellen Segregated Witness-Implementierung aus?

Obwohl ich bei diesen Themen mit Polarisierung bombardiert wurde, bin ich nicht zu dem Schluss gekommen, dass sie sich gegenseitig ausschließen.

Es gibt keinen Kunden, der einen „emergenten Konsens“ hat, der auch SegWit implementiert hat.
@MaxSan github.com/bitcoinec/bitcoinec/pull/3 Das ist nicht wahr, Bitcoin EC tut es und Sie können jetzt auf diesem Zweig aufbauen, wenn Sie möchten, oder Ihren eigenen Client erstellen, der die gleichen Dinge von Grund auf neu macht. Wissen Sie, ob sich ein entstehender Konsens auf die Realisierbarkeit der aktuellen Segwit-Implementierung auswirkt? denn das ist die frage
Es ist eine Art Äpfel und Nudeln zu vergleichen, sobald eine Softfork mit Segwit aktiviert ist, kann man sie nicht mehr rückgängig machen ... das erfordert eine Hardfork, um sie zu entfernen. Wenn verschiedene Personen unterschiedliche Blöcke (nach Größe) akzeptieren, ist dies nicht verwandt, obwohl die Produktion JEDES Nicht-SegWit-Blocks immer noch vom Netzwerk abgelehnt würde. Wenn dies Ihre Frage ist, können Sie eine vollständige Antwort richtig ausarbeiten?
@MaxSan richtig, damit die Leute unterschiedliche Blöcke nach Größe akzeptieren können, die auch Segwit-konform sind. Das ist die offensichtliche Antwort richtig? In erster Linie auf der Suche nach Bestätigung
Richtig. EC hat jedoch seine eigenen Probleme, und es wurden Artikel geschrieben, die darauf hindeuten, dass alles über 4 MB angesichts der aktuellen Umstände sehr schlecht wäre.
@MaxSan "aktuelle Umstände" sind Latenz und Bandbreite der derzeit verbundenen Knoten, die möglicherweise einen wirtschaftlichen Anreiz haben, ihre Konnektivität zu verbessern und möglicherweise die Arten von Knoten zu verschieben, die mit dem Netzwerk verbunden sind? (Zentralisierung wird unabhängig vom Thema eine ständige Bedrohung sein) Gibt es andere Bedenken, die ich vermisse?
Ein Angreifer könnte Angriffsblöcke erstellen, indem er schwer zu verifizierende Transaktionen erstellt, die quadratisch skalieren. SegWit behebt dies und muss implementiert werden, bevor die Blockgröße erhöht wird, ohne das Netzwerk für neue Angriffsvektoren zu öffnen.
@MaxSan, aber dieser bestimmte neue Angriffsvektor könnte einige Zeit existieren, ausgenutzt werden und Knoten dazu veranlassen, auch Segwit zu implementieren? Hm, ich dachte, der getrennte Zeuge, als er aktiv war, war noch ein optionales Vertrauenssystem, also sehe ich nicht, wie er die Verbreitung schwer zu verifizierender Transaktionen verhindern würde

Antworten (1)

Technisch gesehen gibt es keinen Grund, warum die beiden Protokoll-Upgrades nicht in Kombination zu einer Blockchain hinzugefügt werden könnten. Offensichtlich müssten sie für die Kompatibilität in ihrer Behandlung von Blockgewicht/Blockgröße geändert werden. Die wahrgenommene Inkompatibilität rührt hauptsächlich von den radikal gegensätzlichen Visionen her, die die beiden Entwicklerteams in Bezug auf die Skalierungs-Roadmap von Bitcoin zu haben scheinen.

SegWit wurde speziell entwickelt, um eine Kapazitätssteigerung auf eine Weise bereitzustellen, die keine Hard Fork erfordert. Viele seiner Befürworter scheinen zu erwarten, dass eine Hardfork das Bitcoin-Netzwerk dauerhaft spalten wird.

Die Befürworter von Emergent Consensus hingegen scheinen die Position zu vertreten, dass Hardforks Softforks vorzuziehen sind oder sie zumindest als viel weniger riskant wahrnehmen.

Keines der Teams scheint den anderen Vorschlag als Priorität für die Aufnahme in die Codebasis zu betrachten. Ein Brückenvorschlag wurde durch den „BitcoinEC“-Client bereitgestellt, der die Emergent Consensus-Funktion auf Bitcoin Core 0.14 gepatcht hat, die jedoch anscheinend nicht mehr gepflegt wird.