Wird Schnorr Multi-Signaturen ECDSA vollständig ersetzen?

Dabei bin ich auf die Tatsache gestoßen, dass schnorr-Signaturen höchstwahrscheinlich das derzeitige ECDSA-System in einem zukünftigen BIP ersetzen werden .

Lohnt es sich, etwas über ECDSA zu lernen, oder wird dies zu veraltetem/nutzlosem/verwirrendem Wissen?

Oder sollte ich direkt auf Schnorr-Signaturen eingehen, zum Beispiel, wie sich dies auf ein Modell wie dieses auswirkt

Antworten (1)

Schnorr-Signaturen werden ECDSA nicht ersetzen. Es wird erwartet, dass die Schnorr-Signaturüberprüfung mit dem Taproot-Soft-Fork unter Verwendung von SegWit Witness Version 1 implementiert wird. Das bedeutet, dass nur Ausgaben, die in der v1-SegWit-Version gesperrt sind, erwartet werden, dass sie gültige Schnorr-Signaturen erzeugen.

ECDSA wird weiterhin verwendet, um aktuelle Nicht-SegWit- und v0-SegWit-Ausgaben auszugeben. Alle Ausgaben mit dem OP_CHECKSIG-Opcode werden weiterhin den alten ECDSA-Signaturalgorithmus und die Verifizierung verwenden.

Daher ist es wichtig, ECDSA zu verstehen, um die Signaturüberprüfung hinter der Ausgabe aller Ausgaben zu verstehen, die nicht native v1 SegWit sind. Laut txstats.com gehören nur über 2% aller gesperrten BTC-Werte zu nativen SegWit-Skripten, auch das nach fast 2 Jahren Implementierung. Es kann also davon ausgegangen werden, dass die V1-Implementierung möglicherweise nicht alle aktuellen Ausgangssperrskripte vollständig ersetzt, sodass Sie auch den ECDSA-Signaturalgorithmus verstehen müssen, wenn Sie vorhaben, Produkte zu entwickeln, die Bitcoin akzeptieren, für die ECDSA-Signaturen erforderlich sind.

"ein Soft-Fork [...] kann ECDSA nicht entfernen" Dies ist verwirrend formuliert. Ich denke, Sie versuchen zu sagen, dass wir nicht zulassen können, dass ältere OP_CHECKSIG-Operationen durch eine Schnorr-Signatur mit einer Soft Fork erfüllt werden, was richtig ist. Als ich Ihren Satz jedoch zum ersten Mal las, klang es so, als würden Sie sagen, dass wir ECDSA nicht vollständig über einen Soft Fork entfernen könnten, was falsch ist – wir könnten das Legacy-OP_CHECKSIG immer über einen Soft Fork zum Scheitern bringen, da dies einfach wäre die Regeln strenger zu machen.
@DavidA.Harding Ja, du hast recht. Ich glaube, das war eine schlechte Wortwahl von mir.