Kann ein 51%-Angriff erkannt und behandelt werden?

Können solche Angriffe erkannt werden? Ja.

Was Sie sehen würden, ist eine Kettenreorganisation, die eine große (mehr als drei) Anzahl von zuvor akzeptierten Blöcken ungültig macht. Der Standard-Client wird dies tatsächlich protokollieren – Sie sehen ein REORGANIZEin der debug.logDatei des Clients. Der Client protokolliert derzeit nicht die Anzahl der Blöcke, die durch die Reorganisation ungültig gemacht wurden, aber das ist eine einfache Verbesserung.

Können ehrliche Benutzer solche Angriffe rückgängig machen? Art von.

Wenn sich eine Transaktion, die Ihnen wichtig ist, in der Gruppe von Blöcken befindet, die für ungültig erklärt wurde, können Sie diese Transaktion jederzeit erneut einreichen. Sofern der Absender im Rahmen eines Double-Spend-Angriffs keine widersprüchliche Transaktion ausgegeben hat, ist die Transaktion weiterhin gültig. (Das Netzwerk erledigt dies tatsächlich automatisch für Sie. Bergleute möchten die Chance nicht verpassen, die mit den rückgängig gemachten Transaktionen verbundenen Transaktionsgebühren zu kassieren.)

Als längerfristige Lösung wurden Vorschläge diskutiert, Reorganisationen abzulehnen, die eine verdächtig große Anzahl von Blöcken wie vier oder mehr ungültig machen. Das Problem bei diesen Vorschlägen besteht darin, dass unter ungewöhnlichen Umständen (z. B. wenn eine Katastrophe das Internet für eine halbe Stunde partitioniert) das Netzwerk dauerhaft getrennt werden kann, wobei jede Seite die Blockchain der anderen Seite als verdächtige Reorganisation ablehnt.

Im Wesentlichen müsste der Client in diesem Fall in einen „Sperrmodus“ wechseln und alle Transaktionen ablehnen, bis ein Mechanismus zum Auffinden der echten Blockchain implementiert werden könnte. (Es könnte alle Transaktionen an beide Ketten übermitteln und nur Transaktionen, die in beiden Ketten akzeptiert werden, als bestätigt betrachten!) Ein Vorschlag verwendet eine zentrale Autorität, um die echte Kette auszuwählen. Dies ist ein Bereich, in dem es Raum für Innovationen gibt.

Ein wichtiger Punkt, den Sie jedoch beachten sollten: Wenn der Absender keinen Double-Spend-Angriff versucht, müssen Sie sich keine Sorgen machen (außer der verringerten Nützlichkeit eines instabilen Austauschnetzwerks). Sie können die Transaktion so oft wie nötig an die Blockchain senden, bis schließlich ein Block, der die Transaktion enthält, gewinnt. Nur der Absender kann eine widersprüchliche Transaktion erstellen, die es Ihnen unmöglich machen würde, die Transaktion, die Ihnen wichtig ist, in die Kette zu bekommen.

Update: Tatsächlich können Sie Münzen verlieren, selbst wenn der Absender keinen Double-Spend-Angriff versucht hat. Angenommen, A sendet Geld an B und dann sendet B Geld an C, wenn A erfolgreich einen Double-Spend-Angriff verwendet, um die Transaktion, die die Coins an B gesendet hat, ungültig zu machen, kann das Senden von B an C fehlschlagen (weil eine widersprüchliche Transaktion bedeutet, dass B dies nie tun wird die auszugebenden Mittel), obwohl B keinen Double-Spend-Angriff versuchte.

Ein Kommentar zu „von vorne anfangen“.

Mehrere Prüfpunkte wurden in der Client-Quelle hartcodiert (Hashes von Blöcken werden regelmäßig in neuen Versionen des Clients hinzugefügt), um genau die Auswirkungen großer Umschreibungen großer Kettenstücke zu reduzieren. Der in den frühen Tagen von Bitcoin generierte Transaktionsverlauf könnte mit der gesamten Rechenleistung, die den Bergleuten heute zur Verfügung steht, leicht neu geschrieben werden. Aufgrund dieser Kontrollpunkte können neue Kunden jedoch nicht auf diese Weise gelockt werden.

Jemand mit 51 % der gesamten Rechenleistung könnte beginnen, die Historie vom letzten Kontrollpunkt neu zu schreiben, aber er kann nicht weiter in die Vergangenheit gehen. Damit der Angriff effektiv ist, muss man außerdem die Netzwerkkette überholen, bevor der nächste Kontrollpunkt von einer Mehrheit der Knoten akzeptiert wird.

Der Angreifer muss Konsequenzen haben, die groß genug sind, um den Schlag seines eigenen Angriffs zu spüren.

Um die Konsequenz für ihn zu schaffen: Der Wähler (Trusted Node/Full Node) muss Bitcoin haben, und je mehr Bitcoin der Node hat, desto mehr Stimmrecht (mehr Vertrauen haben sie). Wenn der Angreifer beispielsweise wirklich das gesamte Bitcoin-Netzwerk töten will, muss er mindestens 51 % der Bitcoins im Umlauf haben. Wenn ein Bitcoin-Netzwerk 100 Milliarden Dollar wert ist. Er muss es im Wert von 50 Milliarden Dollar kaufen. Versuchen Sie, das Netzwerk zu töten, und er wird seine 50 Milliarden Dollar verlieren. Ja, andere werden etwas an Wert verlieren, aber er wird viel mehr an Wert verlieren, und wir können eine weitere Kryptowährung starten.

Es muss kein lineares 1 Bitcoin = 1 Stimmrecht sein. Es kann eine Funktion sein. wie Stimmrecht = root2 (Bitcoin) oder andere Funktionen.

Das einzige Problem dabei ist, dass die meisten Leute einen zentralisierten Knoten verwenden (weil sie entweder einen leichten Knoten verwenden und keine Ressourcen für einen vollständigen Knoten verschwenden wollen), sodass ihre Stimmrechte irgendwo zentralisiert sein und vom verwendet werden können Angreifer zum Angriff (unter der Annahme, dass mehr Bitcoin = mehr Stimmrecht). Die Lösung hierfür besteht wahrscheinlich darin, eine Verlangsamungsfunktion (wie die Root-Funktion) anzuwenden, um ihre Stimmkraft zu begrenzen. Aber dann kann der Angreifer viele Brieftaschen mit kleinem Wert verwenden, um die große zentralisierte Brieftasche zu untergraben. (Alles in Maßen Taktik, zu viel oder zu wenig ist nicht gut) Also sollten wir auch das Stimmrecht derer senken, die sehr wenig Bitcoin in ihrem Knoten haben – siehe Bild.

Was passiert also mit dem Knoten, der kein Bitcoin hat? Es wird sowieso nutzlos sein, weil sie aus dem Netzwerk saugen werden. Ich würde sagen, ihnen überhaupt keine Bandbreite und Stimmrechte zuzuweisen, da sie ohnehin kein Bitcoin verwenden und nur Netzwerkressourcen verschwenden. Lassen Sie sie vielleicht eine Referenz mit niedriger Priorität sein, nur um sie ein wenig nützlich zu machen.

Gleiches gilt für die Miner. Wir sollten eine ähnliche Funktion wie auf dem Bild zuweisen. Wir wollen nicht, dass große Bergleute das Netzwerk zentralisieren und am Ende zu viel Macht haben, um das Netzwerk zu ruinieren. Da die Bitcoin-Community von den Menschen und für die Menschen ist; Das ist der Sinn der ganzen Sache mit der Dezentralisierung, nicht wahr? Damit wir nicht von der Großmacht schikaniert werden, die alles zentralisieren will. Wir sollten definitiv die große Macht begrenzen, ebenso wie die nutzlosen Leute, die Bitcoin nicht verwenden und aus dem Netzwerk saugen und die echte Gemeinschaft als Ganzes verlangsamen.

Siehe das Bild unten:

Kann dies auch beim Umgang mit dem DDOS-Angriff helfen?

Der Block-Checkpoint-Mechanismus wurde als leistungsstarke Methode für Blockchain-Entwickler beschrieben, um sich vor dem Re-Mining der gesamten Kette zu schützen. Welche Blöcke werden Checkpoints?

Bei der eigentlichen Codeüberprüfung wurde der Block-Checkpointing-Mechanismus in letzter Zeit nicht aktiv verwendet. Der letzte Checkpoint in Bitcoin Version 0.14 ist 295000, der am 9. April 2014 abgebaut wurde. Die Gesamtzahl der Transaktionen seit dem Genesis-Block und der Zeitstempel davon wurden jedoch bis zu Block 446482 am 3. Januar abgebaut. 2017.

Im Vergleich dazu blockiert Litecoin 0.13.2.1 Checkpoints 721000, die am 30. Januar 2015 abgebaut wurde, und dann Transaktion 5502192, abgebaut am 31. Januar 2015. Vermutlich waren sie nicht so fleißig und holen in dieser Hinsicht immer noch zu Bitcoin auf.