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
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.
David A. Harding
Ugam Kamat