Ist das Pruning des Transaktionsverlaufs in Satoshis Bitcoin-Client implementiert?

Seit Bitcoin Core v0.8.0 ist die Validierungsdatenbank („chainstate“ oder „UTXO set“ oder „account balance sheet“) von der Blockchain getrennt. Wenn ein neuer Block hereinkommt, werden seine Auswirkungen (Entfernen verbrauchter Eingaben und Hinzufügen von Ausgaben) auf die Datenbank angewendet. Das bedeutet, dass Blöcke wie zuvor heruntergeladen und verifiziert werden, aber danach nicht mehr zur Validierung verwendet werden. Blöcke werden weiterhin auf der Festplatte gespeichert, um sie an andere zu synchronisierende Knoten zu senden oder um nach alten Transaktionen zu suchen.

Seit Bitcoin Core v0.11.0 ist es auch möglich, in einem echten Pruned-Modus zu laufen, in dem die Blöcke auf der Festplatte nach einer Weile tatsächlich gelöscht werden. Seit v0.12 ist es möglich, das Wallet im Bereinigungsmodus zu verwenden. Seit v0.14 ist es möglich, manuell zu bereinigen (durch Ausgabe eines RPC-Befehls, anstatt die Entscheidung der Anwendung zu überlassen).

Beachten Sie, dass keiner dieser Mechanismen auf dem im Bitcoin-Whitepaper beschriebenen Mechanismus beruht.

Ich würde davon ausgehen, dass dies aufgrund des von Pieter erwähnten Problems nicht implementiert ist. Einen Client zu haben, der nur eine beschnittene Version der Blockchain speichert, kann anderen Clients gegenüber nicht freundlich sein, die diese Pruning-Funktion nicht implementiert haben, da er nicht in der Lage sein wird, die ursprüngliche Blockchain abzurufen.

Da sich eine Vielzahl von Kunden noch in der Entwicklung befindet, um alternativen Kunden die Wahl zu ermöglichen, wie sie mit ihren Blockchain-Daten umgehen, können neue Innovationen ermöglicht werden. Beispielsweise ermöglicht es die Analyse, wie sich Bitcoin im Laufe der Zeit verhalten hat. Auch wenn Sie dies nicht von Anfang an aufgezeichnet haben.

Hier sind zwei Optionen. Der erste kann ein Blockchain-Pool sein, der ein Torrent-ähnlicher Speicher sein wird und unabhängig in Brieftaschen implementiert werden kann (die heutigen 30 GB, die auf 2000 Clients mit 50 % Redundanz verteilt sind, verursachen nur eine Größe von 30 MB).

Zweitens könnte es sich um eine Art Defragmentierung handeln, bei der eine Protokollentwicklung erforderlich ist. Hier wird es kein Problem sein, einen Block oben auf der Blockchain hinzuzufügen, der beispielsweise 100.000 älteste Blöcke als Kopie enthält, ohne Konten mit Nullsaldo. Die Frage ist nur, ob hier eine signifikante Defragmentierungsrate auftritt. Annahmen

• Wir brauchen keine Transaktionen, die leere Konten erstellen (alles wurde gesendet)
• Wir brauchen keine Transaktionen, die den Saldo nicht ändern (alles wurde zurückgeschickt)
• Wir können ein Zeitlimit für tote Konten festlegen (nur eine Transaktion wurde aufgefüllt und das Konto wurde nie verwendet).

Es ist keine einfache Lösung und inaktive Konten können nicht aktualisiert werden, bis sie nicht ausgeführt werden, dann ist das letzte Element nicht ganz sicher.

Nein, es ist der gesamte Verlauf erforderlich, um neue Transaktionen zu verifizieren (da die Sicherheit eines neuen Blocks in der Kette die Sicherheit aller vorherigen Blöcke erfordert).

Einige zukünftige Clients benötigen möglicherweise nicht die gesamte Kette und verifizieren Transaktionen nicht vollständig. Ich würde diese jedoch für große Transaktionen nicht als sicher betrachten, da ich keine Ahnung habe, ob der „dünne Client“, auf dem ich mich befinde, nicht an einer böswilligen Abzweigung in der Kette feststeckt entworfen, um doppelte Ausgaben zu ermöglichen, und jemand ist nicht mit meinen Bitcoins nach Mexiko abgehauen.