Warum benötigen wir einen öffentlichen Schlüssel als Teil von Witness in P2WPKH-Transaktionen?

Da wir die Datennutzlast in einer Blockchain minimieren wollen, was auch zu Konzepten wie SegWit geführt hat und bei der Signaturaggregation usw. diskutiert wird, frage ich mich, warum wir eigentlich öffentliche Schlüssel bereitstellen müssen, um sie auszugeben? Es sind unnötige 33B an Daten. ScriptPubKey könnte so aussehen <HASH160> OP_CHECKSIG2und ScriptSig <Signature>. Ich weiß, dass dies Softfork erfordert, aber als wir SegWit eingeführt haben, warum war das nicht das Design? Liegt es daran, dass die Zuordnung von Signatur -> öffentlicher Schlüssel nicht eindeutig ist?

Bearbeiten:
Wie in den Kommentaren vorgeschlagen: Das Problem bei der Wiederherstellung öffentlicher Schlüssel aus der EC-Signatur ist einfach ein Kompromiss zwischen schneller Verifizierbarkeit und Platzbedarf. Die Wiederherstellung des öffentlichen Schlüssels aus der Signatur (r, s) beinhaltet die Umwandlung des Skalars r = x r in einen Kurvenpunkt R = (x r , y r ) , dh eine modulare Quadratwurzel. Dies wirft eine weitere Frage auf:

Was ist die Idee der Segwit-Transaktionsverifizierung? Haben wir mehrere Ebenen der Validierung von Konsensregeln? Beispielsweise wertet die grundlegende Validierung alle Transaktionsskripte gemäß den Pre-Segwit- Regeln aus (was nur ein Push von 2 Stack-Elementen ist, was immer True ist ), und eine tiefe Validierung, die die Witness-Validierungslogik auslöst. Ich bin mir nicht sicher, ob ich segwit als "Wir haben die Daten von der Transaktion entfernt, die nur einen Eigentumsnachweis darstellen, der zum Zeitpunkt der Bestätigung relevant ist, aber nicht Jahre danach" oder eher wie "Zeugendaten sind fester Bestandteil von Transaktion, so wie sie immer war, und war eigentlich als TX-Malleability-Fix ​​und Generalisierung der Skriptsprache gedacht, die zukünftige Protokollerweiterungen ermöglicht."

Der Fragesteller scheint auf die Fähigkeit anzuspielen, öffentliche Schlüssel aus ECDSA-Signaturen wiederherzustellen, wie in bitcointalk.org/index.php?topic=6430.0 beschrieben
Die Wiederherstellung von Pub-Schlüsseln war im Allgemeinen nicht bekannt, als Bitcoin entwickelt wurde, und hat einige kleine Einschränkungen, wie z. B. eine höhere CPU-Intensität. Der größte Teil der Ressourcennutzung von Bitcoin ist bereits CPU-Zeit.
@Anonym nicht wirklich. Es könnte schneller sein, wenn so viele Schritte kein einzelner Thread wären.

Antworten (1)

Dies wurde heute auf dem IRC-Kanal #bitcoin-wizards diskutiert. Die von Andrew Poelstra (andytoshi) angeführten Gründe waren:

  1. "Segwit hatte schon genug Spielraum." Das heißt, es war bereits eine große Änderung, die einige Leute als umstritten betrachteten, daher wurde die Minimierung weiterer Änderungen als wünschenswert angesehen.

  2. "Die Pubkey-Wiederherstellung ist mit der Batch-Validierung nicht kompatibel." Poelstra erklärt weiter, dass Bitcoin derzeit keine Batch-Validierung für ECDSA und die Gründe dafür hat, aber es klingt für mich nicht so, als wäre eine Batch-Validierung zu einem späteren Zeitpunkt unmöglich (obwohl es vielleicht einen Soft Fork erfordern würde). ); Vermutlich würden Entwickler es vorziehen, stattdessen mit Schnorr-Signaturen an der Batch-Validierung und Signaturaggregation zu arbeiten.

Später fügte Gregory Maxwell (gmaxwell) hinzu, dass „Certicom ein Patent auf Schlüsselwiederherstellung hat, das potenziell anwendbar sein könnte“ auf eine mögliche Konstruktion, die die Verwendung dieser Konstruktion hätte kontrovers machen können.

FYI: Ihre zweite Frage, die in Bearbeitungen gestellt wird, sollte wahrscheinlich separat gestellt werden, da es sich um ein völlig anderes Problem handelt.