#Plume $PLUME Bisher musste jeder Bitcoin Improvement Proposal (BIP), der kryptografische Primitiven benötigte, das Rad neu erfinden. Jeder BIP kam mit einer eigenen, individuellen Python-Implementierung der secp256k1-Elliptischen Kurve und zugehöriger Algorithmen, wobei sich diese jeweils subtil voneinander unterschieden. Diese Inkonsistenzen führten zu stillen Risiken und machten die Überprüfung von BIPs unnötig kompliziert. Dieses Problem wurde kürzlich im Bitcoin Optech Newsletter #348 hervorgehoben, und es ist etwas, das zumindest mehrere Entwickler in der Bitcoin-Entwicklungsgemeinschaft schon lange empfinden: Es sollte einen einheitlichen, wiederverwendbaren Standard für kryptografische BIP-Referenzsecp256k1-Code geben.
Letzte Woche machten Jonas Nick und Tim Ruffing vom Blockstream Research sowie Sebastian Falbesoner große Fortschritte in diese Richtung. Als Teil ihres bestehenden ChillDKG-Vorschlags veröffentlichten sie secp256k1lab. Eine neue, bewusst INSEKURE Python-Bibliothek zum Prototyping, Experimentieren und zur Spezifikation von BIPs. Sie ist nicht für den Produktiveinsatz geeignet (da sie nicht konstant in der Zeit arbeitet und daher anfällig für Seitenkanalangriffe ist), füllt aber eine kritische Lücke: Sie bietet eine saubere, konsistente Referenz für secp256k1-Funktionalität, einschließlich BIP-340-ähnlicher Schnorr-Signaturen, ECDH und Low-Level-Feld-/Gruppenarithmetik. Das Ziel ist einfach: Es soll zukünftige BIPs leichter und sicherer zu schreiben machen, indem redundanten, einmaligen Implementierungen vorgebeugt wird. Für BIP-Autoren bedeutet dies: weniger eigenes Code, weniger Spezifikationsprobleme und ein klarerer Weg von der Prototypenphase zur Vorschlagsphase.
Letzte Woche machten Jonas Nick und Tim Ruffing vom Blockstream Research sowie Sebastian Falbesoner große Fortschritte in diese Richtung. Als Teil ihres bestehenden ChillDKG-Vorschlags veröffentlichten sie secp256k1lab. Eine neue, bewusst INSEKURE Python-Bibliothek zum Prototyping, Experimentieren und zur Spezifikation von BIPs. Sie ist nicht für den Produktiveinsatz geeignet (da sie nicht konstant in der Zeit arbeitet und daher anfällig für Seitenkanalangriffe ist), füllt aber eine kritische Lücke: Sie bietet eine saubere, konsistente Referenz für secp256k1-Funktionalität, einschließlich BIP-340-ähnlicher Schnorr-Signaturen, ECDH und Low-Level-Feld-/Gruppenarithmetik. Das Ziel ist einfach: Es soll zukünftige BIPs leichter und sicherer zu schreiben machen, indem redundanten, einmaligen Implementierungen vorgebeugt wird. Für BIP-Autoren bedeutet dies: weniger eigenes Code, weniger Spezifikationsprobleme und ein klarerer Weg von der Prototypenphase zur Vorschlagsphase.