Wird der gegabelte Zweig der Blockchain eines Angreifers zur Bitcoin-Bestätigung verwendet?

Soweit ich weiß, werden Transaktionen zu einem Block zusammengefasst, der Arbeitsnachweis wird erbracht, indem ein Hash-Wert für den Block berechnet und dann der Blockkette hinzugefügt wird. Wenn der Blockchain ein Block hinzugefügt wird, gilt die im Block enthaltene Transaktion als bestätigt.

Wie wird entschieden, von welchem ​​Full Node die Blockchain abgefragt wird? Oder gegen wie viele Blockchains von vollständigen Knoten wird eine Transaktion geprüft?

Angenommen, ein Angreifer hat eine gegabelte Kette, und lassen Sie uns nichts über die Ablehnung oder Bestätigung dieser Gabelung durch andere vollständige Knoten annehmen. Kann meine Transaktion mit dieser gegabelten Kette des Angreifers und nicht mit anderen gültigen Blockketten, die von ehrlichen vollständigen Knoten verwaltet werden, überprüft werden?

Angenommen, ich habe 6 Bestätigungen erfolgreich durchgeführt, aber alle diese Blöcke sind eine Fork eines Angreifers. Ist das ein Problem?

Ich denke, Sie fragen nach der Situation, in der Sie als Nicht-Vollknoten (z. B. eine SPV-Wallet auf einem Telefon) nur mit Knoten verbunden sind, die vom Angreifer betrieben werden? Und dann werden Sie dazu verleitet, der Kette des Angreifers zu glauben.

Antworten (3)

Ihr Szenario ist nicht ganz klar, weil Sie uns nicht mitteilen, ob der Angreifer gültige Blöcke oder ungültige Blöcke produziert. Sie haben auch nicht definiert, ob Ihr eigenes Wallet ein Full-Node oder ein Thin Client ist.

Lassen Sie uns zunächst darüber sprechen, wie Blöcke durch das Netzwerk weitergeleitet werden:
Wenn ein neuer Block entdeckt wird, gibt ein Knoten über eine inv(Bestands-)Nachricht bekannt, dass er diesen neuen Block hat. Andere vollständige Knoten senden eine getdataNachricht und fordern den gesamten Block an. Nachdem sie die Daten erhalten und validiert haben, senden sie eine invNachricht an ihre Kollegen, um ihnen den neuen Block anzukündigen.
SPV-Knoten fordern nicht den vollständigen Block an. Sie erhalten nur den Block-Header, und wenn es interessante Transaktionen gibt, fordern sie ausdrücklich einen Nachweis für diese per merkleblockNachricht an. SPV-Knoten können die Gültigkeit neuer Blöcke nicht vollständig überprüfen, da sie die Blockchain nicht speichern.

Jetzt gibt es drei verschiedene mögliche Szenarien und zwei Arten von Wallets, die es zu berücksichtigen gilt:

Angreifer produziert ungültige Blöcke
Ein SPV-Wallet kann getäuscht werden, da es die Gültigkeit eines Blocks nicht überprüfen kann. Sie prüfen immer noch, ob die Block-Header wohlgeformt sind. Einige SPV-Wallets benötigen mehrere Peers, um ihnen denselben Block mitzuteilen. Daher kann dieser Angriff zusätzlich einen Sybil-Angriff oder die Kontrolle der Internetverbindung des SPV-Wallets erfordern .
Vollständige Knoten sind nicht betroffen, da sie ungültige Blöcke ablehnen.

Angreifer produziert gültige Blöcke mit niedriger Geschwindigkeit
. Ein SPV-Wallet reorganisiert sich zu einer längeren Kette, wenn es von einem anderen Peer davon erfährt. Auch hier muss die SPV-Wallet von anderen Informationen isoliert werden, damit dies funktioniert. Da die Informationen gültig sind, kann dieser Angriff auch gegen vollständige Knoten funktionieren. Dem Angegriffenen fällt möglicherweise die verdächtig langsame Aktualisierungsrate auf.

Der Angreifer produziert gültige Blöcke mit 51 % der Mining-Leistung
. Der Angreifer ist schneller als der gesamte Rest des Netzwerks. Indem er sich dafür entscheidet, nur auf seinen eigenen Blöcken aufzubauen, kann er 100 % der Blöcke abbauen und trotzdem das verbleibende Netzwerk übertreffen. Die Blöcke sind gültig und werden daher von allen Knoten akzeptiert (bis zu einer Art Eingriff). Der Angreifer kann Transaktionen zensieren und sogar eine kleine Anzahl von Blöcken zurücksetzen, indem er von einem früheren Block ausgeht, aber schließlich die natürliche Blockchain-Spitze überholt. Dies wird als Mehrheitsangriff bezeichnet und bricht die axiomatische Sicherheitsannahme von Bitcoin, dass mehr als die Hälfte der Mining-Power ehrlich ist.

Wie sicher sind sechs Bestätigungen im Fork eines Angreifers?
Wenn Sie in einen Sybil-Angriff geraten, wird Sie das täuschen. In allen anderen Fällen werden Sie nicht getäuscht, oder das gesamte Netzwerk ist das Ziel.

Sobald Sie eine Transaktion gesendet haben, übertragen Sie sie an das Netzwerk. Alle Full Nodes erhalten das und werden die Transaktion verifizieren, daher ignorieren Full Nodes die falschen Blöcke, wenn sie von Bergleuten übermittelt werden, und warten in Zukunft auf den richtigen Block und gehen davon aus, dass mehr als 50 % der Bergleute ehrlich sind, dass falsche Blöcke verwaist sein werden.
SPV-Clients suchen jedoch nur nach der längsten Kette und werden in diesem Fall vom falschen Block getäuscht.
Der von Ihnen beschriebene Angriff ist ein 51%-Angriff, bei dem der Angreifer 50% und mehr der gesamten Hashing-Power hat und daher in der Lage ist, gefälschte Blöcke übereinander zu erstellen, was zu einer wirklich verheerenden Situation führen kann und definitiv ein Problem darstellt.

„unter der Annahme, dass mehr als 50 % der Miner ehrlich sind, wird der falsche Block verwaist sein.“ Sie müssen nicht davon ausgehen, dass mehr als 50 % ehrlich sind. Selbst wenn nur ein Miner ehrlich ist, wird die gültige Kette fortgesetzt. Die ungültigen Blöcke werden einfach vollständig ignoriert, sodass die Kette überhaupt nicht wächst. Dies ist der Fall, wenn es um ungültige Blöcke geht (falsche Signaturen, zu hohe Blockbelohnung usw.). Beachten Sie, dass doppelte Ausgaben KEINE ungültigen Transaktionen sind. Beide Transaktionen SIND gültig, aber nur eine davon landet in der endgültigen Blockchain.
Ja, es ist wichtig, doppelte Ausgaben und ungültige Transaktionen zu unterscheiden, und ich denke, die Frage hat das nicht klar gemacht. "Selbst wenn nur ein Miner ehrlich ist, wird die gültige Kette fortgesetzt." aber die gültige Kette wird vom Netzwerk nicht akzeptiert, da es keinen gültigen Arbeitsnachweis hat. Es ist, als ob Sie selbst eine gültige Blockchain unterhalten, sich aber nicht um Sie kümmern! Die gültige Kette ist nicht gültig, bis sie den Arbeitsnachweis erhält. Es wird auch ein Problem für SPVs sein, da sie nur der längsten Kette folgen, die Arbeit in sie gesteckt hat.

Die im verwaisten Block verlorene gültige Trxid wird mit verzögerter Bestätigung im System in den nächsten verfügbaren Block eingereiht.

Der Grund für die Beibehaltung von zehnminütigen Lücken in jedem Block besteht darin, die Wahrscheinlichkeit zu verringern, dass 6 aufeinanderfolgende Transaktionen stattfinden.

Digitale Transaktionen mit schnellerer Blockrate oder geringerer Hashing-Leistung sind anfälliger für ein solches Ereignis

"Die im verwaisten Block verlorene gültige Trxid wird mit verzögerter Bestätigung im System in den nächsten verfügbaren Block eingereiht." Das scheint die Frage nicht zu beantworten. OP fragt nach der Situation, in der ein Client vom Netzwerk abgeschnitten ist und nur Blöcke des Angreifers sieht. Ich glaube.
"Der Grund für die Beibehaltung von zehnminütigen Lücken in jedem Block besteht darin, die Wahrscheinlichkeit zu verringern, dass 6 aufeinanderfolgende Transaktionen stattfinden." Das macht keinen Sinn. Sie können 100 aufeinanderfolgende Transaktionen sogar in einem Block platzieren, wenn Sie möchten. 10 Minuten haben damit nichts zu tun.
"Der Grund für die Beibehaltung von zehnminütigen Lücken in jedem Block besteht darin, die Wahrscheinlichkeit zu verringern, dass 6 aufeinanderfolgende Transaktionen stattfinden." das ergibt für mich keinen sinn. Das hat nichts mit 10-Minuten-Blöcken zu tun. Diese Antwort scheint die OP-Fragen nicht zu beantworten.