Quadratisches Hashing-Problem: Warum nicht einfach einen neuen OP-Code "CHECKSIG2" erstellen, um ihn zu beheben?

Warum können "wir" das quadratische Hashing-Problem nicht OP_CHECKSIGmit einer Soft Fork lösen?

Aktualisieren Sie NO_OPxauf OP_CHECKSIG2mit Soft Fork, wo OP_CHECKSIG2nicht quadratisch gehasht wird (verwendet vielleicht einen einzigen TX-Hash aller Daten für jede Eingabe?). Erstellen Sie einen neuen Transaktionstyp für den neuen Prozess wie P2SH und nach einer ausreichend breiten Netzwerkakzeptanz, Soft-Fork, um alle alten OP_CHECKSIGTransaktionen ungültig zu machen, so wie BIP 66 funktionierte?

Oder gibt es ein grundsätzliches Problem mit meiner Annahme, dass "verwendet vielleicht einen einzigen tx-Hash aller Daten für jede Eingabe" überhaupt möglich ist?

Antworten (2)

Hinweis: Ab 2020 ist diese Antwort veraltet, da BIP143 / SegWit seit Jahren verwendet wird, wodurch dieses Problem behoben wird.

Sie können es auf diese Weise beheben, und jemand ist dabei, dies zu tun.

Das Problem beim Hashing der gesamten Transaktion besteht darin, dass Sie die Signatur kennen müssen, um einen Transaktions-Hash zu erstellen. Um die Signatur zu erstellen, müssen Sie jedoch den Transaktions-Hash kennen. Damit dies funktioniert, müssen Sie vermeiden, die scriptSig zu hashen. Dies ist, was Bitcoin tut, aber die Art und Weise, wie es implementiert ist, hindert Sie daran, den Hash für eine Ausgabe zu nehmen und ihn für eine andere zu verwenden.

BIP143 (Teil von Segregated Witness) schlägt ein System vor, bei dem Daten (meistens) einmal gehasht werden.

Ein neuer Transaktions-Digest-Algorithmus wurde definiert, gilt aber nur für sigops im Witness-Programm der Version 0:

Double SHA256 der Serialisierung von:

  1. nVersion der Transaktion (4 Byte Little Endian)
  2. hashPrevouts (32-Byte-Hash)
  3. hashSequence (32-Byte-Hash)
  4. Endpunkt (32-Byte-Hash + 4-Byte-Little-Endian)
  5. scriptCode der Eingabe (serialisiert als Skripte in CTxOuts)
  6. Wert der Ausgabe, die von dieser Eingabe ausgegeben wird (8-Byte-Little-Endian)
  7. nReihenfolge der Eingabe (4 Byte Little Endian)
  8. hashOutputs (32-Byte-Hash)
  9. nLocktime der Transaktion (4-Byte Little Endian)
  10. Sighash-Typ der Signatur (4-Byte-Little-Endian)

Dies wird für jede Eingabe ausgeführt. Jeder Teil davon hat eine feste Länge, mit Ausnahme von scriptCode, aber es gibt keine Möglichkeit, einen scriptCode durch mehrere Eingaben zu hashen. Es gibt drei Eingaben, die auf Informationen variabler Länge basieren, hashPrevouts, hashSequence und hashOutputs, aber dort gibt es nur begrenztes Potenzial für Unheil. Alle Methoden zu ihrer Berechnung hashen entweder eine Eingabe/Ausgabe oder werden von der gesamten Transaktion geteilt oder sind alle Nullen.

Die Validierung sehr großer BIP143-Transaktionen dauert linear und wird von der Signaturüberprüfung dominiert. BIP143-Transaktionen können jedoch derzeit nicht durchgeführt werden, da getrennte Zeugen von den Bergleuten nicht akzeptiert wurden.

Ich verstehe, dass Signaturen nicht signiert werden können. Ich glaube, ich weiß nicht, warum der Hash für jede Eingabe-Sig unterschiedlich ist. Wenn alle Zeichen vor dem Hashing entfernt werden, warum wird dann nicht der gesamte Blob nur einmal für die gesamte Transaktion gehasht?
Weil jeder Hash etwas etwas anderes hasht. Die Referenzen von BIP143 gehen näher darauf ein, aber Sie sollten sich besonders en.bitcoin.it/wiki/OP_CHECKSIG TL;DR ansehen: Die Eingabe, für die Sie signieren, enthält einen Teil des scriptPubKey der vorherigen Transaktion. Dies ist konsenskritisch; Um es zu ändern, ist ein Hardfork oder die Schaffung einer neuen Methode zum Signieren von Transaktionen erforderlich.
Aber es ist nur für den Konsens entscheidend, OP_CHECKSIGoder? Was wäre, wenn es nur einen neuen Operationscode gäbe, der anders signiert wäre?
Das gilt nur für OP_CHECKSIG, richtig. Der neue Opcode ist ein Daten-Push von einem Byte von 0 bis 16.
Warum also nicht einen OP_CHECKSIG2neuen TX-/Adresstyp als Soft Fork hinzufügen, der den gesamten TX minus Sigs einmal hasht und diesen Hash für jede Eingabe verwendet?
Das wäre eine vernünftige Lösung, und es würde in den meisten Fällen gut funktionieren. 143 erlaubt jedoch ANYONECANPAY und SINGLE, was nicht funktionieren würde, wenn nur einmal gehasht würde.

Ich glaube nicht, dass Sie CHECKSIG so softforken können. Skript würde so aussehen

sig pubkey DUP HASH keyhash EQUALVERIFY NOPX/CHECKSIG2

Ein neuer Client würde dies überprüfen und am Ende eine gültige TX erhalten. Der alte Client würde bei NOPX nichts tun und mit einem ungültigen TX enden.

Quadratisches Hashing-Problem: Warum nicht einfach einen neuen OP-Code "CHECKSIG2" erstellen, um ihn zu beheben?
AntwortenHierDatenschutz-Bestimmungen1y, 0v