nach Hard Fork geht nicht jede neue Transaktion auf beide Chains?

Dies geschah tatsächlich bei Ethereum, als sie eine Hard Fork hatten. Wenn eine Transaktion in beiden Ketten gültig ist (Ausgaben vor der Gabelung ausgibt) und an beide Ketten weitergegeben wird, dann ja, es gibt keinen Grund, warum sie nicht zu Blöcken in beiden Ketten hinzugefügt wird.

Es gibt jedoch immer noch zwei Ketten. Wenn dieselbe Transaktion zu beiden Ketten hinzugefügt wird, sind sie in zwei separaten Blöcken enthalten; ein Block von Kette A und ein Block von Kette B. Die Ausgaben solcher Transaktionen können nur in ihrer entsprechenden Kette ausgegeben werden, obwohl die Transaktion, die sie erstellt hat, identisch war.

Nehmen wir an, wir haben eine Kette, die sich auf Blockhöhe 100 hartgabelt. Wir haben jetzt Kette A und Kette B. Eine Transaktion wird unter Verwendung von UTXOs aus dem Block auf Höhe 90 erstellt und in beiden Netzwerken verbreitet. Kette A enthält es in ihrem Block auf Höhe 108, und Kette B enthält es in ihrem Block auf Höhe 110 (obwohl es genauso gut auch 108 in ihrer Kette sein könnte). Jetzt wird eine neue Transaktion erstellt, die einen UTXO von der ersten Transaktion auf Kette A ausgibt. Diese zweite Transaktion kann sich immer nur auf Kette B ausbreiten, wenn sie ausschließlich von UTXOs auf beiden Ketten ausgibt. Dies wird mit der Zeit immer unwahrscheinlicher.

Da die meisten neuen Transaktionen auf einer Kette nur für diese Kette gültig sind, wird es nicht lange dauern, bis die beiden Ketten kaum noch Transaktionen gemeinsam haben.

Es ist auch wichtig zu beachten, dass Bitcoin-Clients Verbindungen zu Clients unterbrechen, die Blöcke von der anderen Kette verbreiten. Dies wird dazu beitragen, das Netzwerk zu trennen und zu verhindern, dass sich Transaktionen auf beiden Ketten ausbreiten, selbst wenn sie auf beiden gültig sind. Es könnte böswillige Entitäten geben, die die beiden Netzwerke „überbrücken“ und nach Transaktionen suchen, die für beide gültig sind, aber es gibt keinen wirklichen Anreiz für diese Art von Fehlverhalten.

Lassen Sie uns ein Beispiel für eine Hard-Fork-Blockkette darstellen:

A <-- B <-- C  <-- D   (current consensus rules chain, "original chain")       
      ^---- C' <-- D'  (new consensus rules chain, "new chain")

Wenn Sie in Block A oder B eine Transaktionsausgabe erhalten haben, können Sie diese sowohl für die ursprüngliche Kette als auch für die neue Kette ausgeben[*]. Wie das funktionieren würde, hängt stark davon ab, ob die neue Kette einen Wiederholungsschutz enthält.

Replay-Schutz

Die neue Kette kann optional einen Wiedergabeschutz erfordern, was höchstwahrscheinlich eine Änderung der Daten wäre, die zum Erstellen der Transaktionssignatur verwendet werden. Beispielsweise signiert eine Transaktionssignatur normalerweise einen Hash der Kennung der ausgegebenen Eingaben sowie aller Ausgaben; für eine Hard Fork könnte dies dahingehend geändert werden, dass der Signatur-Hash zusätzlich den Wert „Hard Fork #123“ enthalten muss. Dies hätte folgende Ergebnisse:

1. Die alte Kette würde keine Transaktionen für die neue Kette akzeptieren, weil sie nicht versuchen würde, den Signatur-Hash mit den zusätzlichen „Hard Fork #123“-Daten zu berechnen, sodass alle für die neue Kette erstellten Signaturen für sie ungültig erscheinen würden.

2. Die neue Kette würde keine Transaktionen akzeptieren, die für die alte Kette getätigt wurden, da ihnen die erforderlichen „Hard Fork #123“-Daten fehlen würden.

Für die meisten (wahrscheinlich alle) Wallets wäre das Hinzufügen von „Hard Fork #123“ zu den Daten, die zum Erstellen des Signatur-Hashs verwendet werden, technisch einfach – aber es erfordert, dass der Wallet-Autor den Fork unterstützt und dass alle Benutzer vor dem Fork ein Upgrade durchführen. Schwieriger (je nach Wallet) wäre es, beide Signaturformate zu unterstützen und dem Benutzer vielleicht die Wahl zwischen ihnen zu ermöglichen. Trotzdem könnte ich mir vorstellen, dass es nicht zu schwer ist.

Die meisten vorgeschlagenen Hard Forks für Bitcoin enthalten jedoch weder diesen noch einen anderen direkten Wiedergabeschutz. Dies liegt wahrscheinlich daran, dass ihre Antragsteller der Meinung sind, dass die Wahrscheinlichkeit einer Übernahme geringer ist, wenn Entwickler und Benutzer Maßnahmen ergreifen müssen, um die Hard Fork zu verwenden.

Interessanterweise enthielt die ursprüngliche 0.1-Version des Bitcoin-Protokolls drei Opcodes ( OP_VER, OP_VERIF, und OP_VERNOTIF), die für den Wiedergabeschutz während einer Hard Fork verwendet werden konnten, indem Sie angeben konnten, welche Regeln befolgt werden mussten, um Ihre Transaktion für verschiedene Versionen des Protokolls auszugeben .

Leider funktionierte das Design nicht und Satoshi Nakamoto entfernte die Opcodes aus dem Protokoll. Sie bieten nicht nur Schutz vor Wiederholungen nach einer Hard Fork, sondern könnten auch dazu verwendet werden, eine Art von Hard Fork zu verursachen, die als Konsensversagen bezeichnet wird . (Und wenn Sie das aktuelle Drama verfolgen, ist es der Belustigung einiger Leute nicht entgangen, dass das früheste Protokoll von Bitcoin erlaubte, dass eine Hard Fork durch eine . ausgelöst wurde VER.)

Inkompatible Transaktionen

Wenn also ein Wiederholungsschutz verfügbar ist, könnten Sie eine Ausgabe von entweder Block A oder Block B für jede Kette ausgeben, aber Sie müssten die Transaktion für jede Kette anders signieren – um sicherzustellen, dass Sie Gelder auf die ursprüngliche Kette senden können Alice und die Gelder über die neue Kette zu Bob.

Ohne Replay-Schutz müssen Sie das Geld auf beiden Ketten gleichzeitig senden, da jede Transaktion, die Sie erstellen, auf beiden Ketten gültig ist[*]. Es gibt jedoch Möglichkeiten, Transaktionen zu erstellen, die nur für eine Kette gültig sind, auch wenn kein Wiedergabeschutz verfügbar ist – sie sind nur schwieriger:

• Verwendung von Coinbase-Münzen: Die Blöcke C (ursprüngliche Kette) und C' (neue Kette) haben unterschiedliche Coinbase-Transaktionen. (Eine Coinbase-Transaktion ist die spezielle Transaktion in einem Block, die den Miner für die Erstellung dieses Blocks bezahlt.) Diese Transaktionen sind nur in ihrer bestimmten Kette gültig, und alle Transaktionen, die von ihnen abstammen, sind ebenfalls nur in ihrer bestimmten Kette gültig.

  Wenn Sie also ein Miner sind oder einen Miner kennen, müssen Sie nur mindestens 1 Satoshi von ihnen mit Ihren Ausgaben aus Block A mischen, und Ihre Transaktion verfügt über einen Ad-hoc-Wiederholungsschutz.

  Allerdings gibt es dabei zwei Probleme: (1) Sie müssen einen Miner kennen, der bereit ist, Ihnen zu helfen, und (2) Coinbase-Transaktionen können nicht für 100 Blöcke ausgegeben werden[*], also müssten Sie eine Weile warten nach dem Hard Fork, bevor Sie anfangen konnten, Geld auszugeben.

• Widersprüchliche Transaktionen: Wenn Sie zwei verschiedene Transaktionen erstellen und an die beiden verschiedenen Blockchains senden, ist es möglich (aber nicht garantiert), dass eine Transaktion in Block C und eine Transaktion in Block C' bestätigt wird.

  Solange die Blöcke C und C' Teil ihrer jeweiligen Blockchain bleiben, können alle Transaktionen, die Ihre Transaktion ausgeben, nur Teil ihrer jeweiligen Blockchain sein.

  Da es keine Garantie dafür gibt, dass Sie Coins auf diese Weise aufteilen können, ist es normalerweise eine gute Idee, beide separaten Transaktionen an sich selbst zu senden, damit Sie auf keinen Fall Geld über die Transaktionsgebühren hinaus verlieren können. Außerdem gibt es eine Möglichkeit, Ihre Chancen zu erhöhen, dass die Coins geteilt werden:

  • Geben Sie auf der Kette mit der höchsten Blockhöhe Ihre Münzen für sich selbst aus, indem Sie nLockTime verwenden, um die aktuelle Blockhöhe zu erreichen.

  • Wenn die obige Transaktion bestätigt wird, geben Sie Ihre Münzen für sich selbst in der anderen Kette ohne nLockTime aus.

   

  Unter der Annahme, dass die verschiedenen Ketten auch nur einen geringfügigen Höhenunterschied aufweisen, funktioniert dies, da Ihre nLockTime-Transaktion zunächst nur auf der Kette mit höherer Höhe gültig ist und daher nicht sofort zur Kette mit niedrigerer Höhe hinzugefügt werden kann. (Credit: Ich habe zum ersten Mal von einer Methode wie dieser von Peter Todd gehört; ich weiß nicht, ob er sie entwickelt hat, noch ob dies genau die Methode ist, an die er dachte – ich musste von ihm erraten, wie sie funktionieren würde Sagen Sie einfach "nLockTime verwenden".)

Eine Warnung

Hard Forks, insbesondere solche ohne Wiederholungsschutz, brechen mit vielen normalen Annahmen von Bitcoin-Wallets. Daher besteht ein erhebliches Risiko, dass Sie Geld verlieren, wenn Sie Bitcoins während einer laufenden Hard Fork ausgeben oder annehmen. Bitte seien Sie vorsichtig.

[*] Hard Forks können jeden Teil des Systems ändern, daher gelten die Verallgemeinerungen in diesem Beitrag möglicherweise nicht für alle Fälle. Ich habe jedoch versucht, sie auf die meisten vorgeschlagenen Hard Forks anwendbar zu machen, die nur ein paar Dinge ändern, wie z. B. die ständig diskutierte maximale Blockgröße/-gewicht.