Warum ist das Wertfeld 8 Bytes in der Transaktionsausgabe, wenn es mit 7 Bytes erreicht werden kann?

Bitcoin verwendet ein 8-Byte-Wertfeld in der Transaktionsausgabe. Das Gesamtangebot an Bitcoin ist jedoch auf 21 Mio. begrenzt. Selbst wenn alle 21 Millionen Bitcoins an eine einzige Adresse übertragen werden, kann die Ausgabe nach der Konvertierung in Satoshis theoretisch effektiv mit 7 Datenbytes dargestellt werden. Das bedeutet, dass wir für jede in der Blockchain gespeicherte Transaktion mindestens 2 Bytes redundanter Daten hinzufügen (eines für die Ausgabeadresse und das andere für die Änderungsadresse). Gibt es einen bestimmten Grund, warum eine Größe von 8 Byte gewählt wurde, oder war dies ein Designfehler, der von Satoshi übersehen wurde? Ist es möglich, dies über eine Soft-Fork zu ändern, oder erfordert die Änderung eine Hard-Fork?

Antworten (2)

Gibt es einen bestimmten Grund, warum eine Größe von 8 Byte gewählt wurde?

Wahrscheinlich nicht.

Im ursprünglichen Bitcoin-Quellcode waren viele der in Datenstrukturen verwendeten Primitive einfach die In-Memory-Darstellungen dieser Primitive. Bei Ganzzahlen ist dies eine 32-Bit-Little-Endian-Ganzzahl (4 Byte). 32 Bit reichen jedoch nicht aus, um alle Satoshis darzustellen, die in Bitcoin vorhanden sind. Das nächste Primitive, das verwendet werden kann, ist ein Long, auch bekannt als 64-Bit-Integer. Da dies nur so serialisiert wurde, wie es im Speicher dargestellt wird, sind die Beträge letztendlich 64-Bit-Little-Endian-Werte.

Ist es möglich, dies über eine Soft-Fork zu ändern, oder erfordert die Änderung eine Hard-Fork?

Das Serialisierungsformat, das zur Berechnung des Gewichts und der Hashes verwendet wird, kann nur über einen Hard Fork geändert werden.

Sie können jedoch eine Transaktion mit einer beliebigen Serialisierung übertragen, solange dieses Format alle notwendigen Informationen enthält, um die Serialisierung zu erstellen, die für die Berechnung von Gewicht und Hash erforderlich ist. Dies würde keinen Fork erfordern, da es sich nicht um eine Konsensänderung handelt.

Ja, das Transaktionsformat hat ungenutzte Bytes. Ein weiteres Beispiel ist die Codierung des utxo-Index in vier Bytes. Niemanden interessierts. Wir können das Format nicht ohne Hard-Fork ändern. Und wir wollen es nicht tun. Lebe damit.

Bei UTXO bin ich anderer Meinung. Das Blocklimit von 1 MB wurde später von Satoshi im Juli 2010 eingeschlichen. Davor hätten Sie also eine Anzahl von Ausgängen haben können. Die Anzahl der möglichen Ausgaben wäre also durch die 4 Bytes des vout-Index begrenzt.
Ich stimme nicht zu, dass es uns egal ist oder wir es ohne Hard Fork nicht ändern können. Es ist trivial, effizientere Wege zum Speichern und Kommunizieren von Transaktionen und Blöcken zu entwerfen; nur die Daten, die Hash-Funktionen für txids und andere Verpflichtungen zugeführt werden, müssen ohne Verzweigung konsistent bleiben.
@PieterWuille Wenn Sie die Ausgabewertgröße auf 7 Bytes ändern, betrachten die Knoten, auf denen eine ältere Version von Bitcoin Core ausgeführt wird, diese Transaktionen nicht als ungültig, was zu einer Verzweigung führt?
@UgamKamat Sie würden einfach eine neuere Protokollversion aushandeln, bei der das 8. Byte weg ist. Dieses Protokoll würde nur zwischen zwei Peers verwendet, die es unterstützen. Es ist wichtig zu erkennen, dass Transaktionen und Blöcke zwar oft als Bytes betrachtet werden, aber in Wirklichkeit nur abstrakte Strukturen sind und Sie sie beliebig codieren können - solange alle Teilnehmer an der Kommunikation immer noch die richtigen Hashes berechnen können (die sind definiert in Bezug auf eine bestimmte Serialisierung).
@PieterWuille Das war eine gute Erklärung, wie wir es auf 7 Bytes reduzieren können. Wird in zukünftigen Versionen redundante Größen auf der Liste reduziert? Wir können einen guten Prozentsatz der Blockchain-Größe in Zukunft reduzieren.
@UgamKamat Es gibt viele weitere Redundanzen im Protokoll (Größen, DER-Codierung für Sigs, vorhersehbare Sperrzeiten und Sequenznummern, Standardskriptvorlagen, redundante Skripte in P2SH-Wrapper-Segwit-Ausgaben, ...), die durch eine spezielle Komprimierung vermieden werden könnten planen. Ich habe daran etwas gearbeitet, aber es hat keine sehr hohe Priorität. Außerdem handelt es sich hauptsächlich um Bandbreiteneinsparungen; Wenn die Blockchain-Größe ein Problem darstellt, führen Sie einfach einen Pruning-Knoten aus.