393 / 736SIPA

Pieter Wuille

Als sipa bekannter Entwickler

Pieter Wuille hat mitgestaltet, wie Bitcoin-Wallets Schlüssel erzeugen, Adressen darstellen und Zahlungen signieren. Vielleicht nutzen Sie seine Arbeit längst, ohne den Namen sipa zu kennen.

Pieter Wuille, bekannt als sipa, ist Bitcoin-Entwickler und Autor oder Mitautor von BIP 32, SegWit, Bech32, Bech32m und Schnorr/Taproot. Ein BIP ist ein öffentlicher technischer Vorschlag. Sein Beitrag besteht in konkreten, gemeinsam entwickelten Lösungen, nicht im Recht, für das gesamte Netzwerk zu entscheiden.

Wenn eine Wallet eine neue Adresse anbietet oder eine Zahlung signiert, steckt hinter der einfachen Schaltfläche die Arbeit vieler Entwickler. Einer davon ist Pieter Wuille. Auf GitHub verwendet er den Namen sipa; sein Profil verbindet diesen Namen mit seiner Entwicklungsarbeit. Wer eine bestimmte Idee beigetragen hat, ergibt sich aber aus der Projektgeschichte und Dokumentation, nicht allein aus einem Benutzernamen. Die folgenden Vorschläge zeigen, welche Probleme er mit wem bearbeitet hat. [1]

Stellen Sie sich einen Laden vor, der für jede Bestellung eine andere Zahlungsadresse nutzen möchte. Wuille beschreibt in BIP 32, wie aus einem Seed, den geheimen Ausgangsdaten, ein ganzer Schlüsselbaum entsteht. Ein erweiterter öffentlicher Schlüssel, xpub genannt, kann weitere öffentliche Schlüssel des entsprechenden Zweigs erzeugen, ohne Ausgaben zu erlauben. Ein privater Schlüssel ermöglicht dagegen das Signieren. Wichtig ist eine Ausnahme: Kennt jemand neben dem xpub einen geleakten, nicht gehärtet abgeleiteten privaten Nachfahrenschlüssel, kann der private Elternschlüssel offengelegt werden. Gehärtete Ableitung, auch hardened derivation genannt, unterbricht diesen Weg. Auch wegen der erkennbaren Zahlungszusammenhänge sollte man einen xpub nicht unbedacht teilen. [2]

Weitere Zahlungen können auf einer Transaktion aufbauen. Deshalb ist ihre Kennung wichtig. BIP 141 von Eric Lombrozo, Johnson Lau und Pieter Wuille trennt Prüfungsdaten namens witness, einschließlich der Signaturen, von dem Teil, der die bisherige Kennung txid bestimmt. Die neue Kennung wtxid enthält auch den witness. Eine Änderung der Signaturdaten muss dadurch die txid, auf die sich eine weitere Transaktion bezieht, nicht verändern. Signaturen werden weiterhin geprüft: Eine kryptografische Bindung in der coinbase-Transaktion, der ersten Transaktion des Blocks, schützt die witness-Daten. [3]

Beim Übertragen einer Adresse passiert leicht ein kleiner Fehler. Wuille und Greg Maxwell beschrieben in BIP 173 Bech32 für native SegWit-Adressen. Die Prüfsumme besteht aus Zeichen, die helfen, eine beschädigte Schreibweise zu erkennen. Sie prüft jedoch die Kodierung, nicht die Identität des gewünschten Empfängers. Ersetzt jemand die Adresse durch eine andere gültige Adresse, erkennt die Prüfsumme darin keinen Betrug. [4]

Auch ein Adressformat lässt sich verbessern. Wuille änderte in BIP 350 die Prüfsumme, um eine bestimmte Schwäche beim Einfügen oder Löschen von Zeichen zu beheben. Daraus entstand Bech32m. Die Wallet muss witness-Version und Kodierung abgleichen: Version 0 verwendet weiterhin Bech32, die Versionen 1 bis 16 verwenden Bech32m. Nutzer sollen den Algorithmus nicht von Hand wählen müssen. Die Software muss Adressen richtig erzeugen und prüfen; irgendeine gültige Prüfsumme reicht nicht. [5]

Eine digitale Signatur macht die Berechtigung zu einer Zahlung überprüfbar, ohne den privaten Schlüssel offenzulegen. BIP 340 von Pieter Wuille, Jonas Nick und Tim Ruffing legt Schnorr signatures mit 64 Byte langen Signaturen und 32 Byte langen öffentlichen Schlüsseln fest. Byte bezeichnet eine Datengröße. Die mathematischen Eigenschaften ermöglichen Systeme, in denen mehrere Menschen gemeinsam signieren. Schlüssel einfach zu addieren genügt dafür aber nicht: Ein gesondertes Protokoll muss die Beteiligten sicher koordinieren. [6]

Eine Wallet kann einen normalen Ausgabenweg und zusätzliche Bedingungen für den Notfall vorsehen. Pieter Wuille, Jonas Nick und Anthony Towns beschreiben Taproot in BIP 341. Über den key path kann eine Signatur genügen, ohne überhaupt die Existenz alternativer Skripte zu verraten. Ein Skript ist ein Programm, das Ausgabebedingungen ausdrückt. Wird der script path gebraucht, werden das verwendete Skript und sein Zugehörigkeitsnachweis veröffentlicht; ungenutzte Alternativen müssen nicht vollständig offengelegt werden. Das spart Platz und schützt manche Informationen über die Wallet, macht aber nicht automatisch jede Zahlung anonym. [7]

Diese Änderungen lösen konkrete Probleme und lassen andere Entwurf und Code prüfen. Bitcoin.org erläutert, dass ein BIP öffentlich diskutiert wird und die Übernahme von den Netzwerkteilnehmern abhängt. Ein Node ist ein Computer, der Transaktionen und Blöcke nach seiner Software prüft. Weder Urheberschaft noch die Pflege eines Repositorys verleihen das Recht, die Konsensregeln einseitig zu ändern. Wuille ist wegen seiner Beiträge und Zusammenarbeit wichtig, nicht als Chef von Bitcoin. [8]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Craig Wright, Gregory Maxwell, Satoshi Nakamoto. Auf diesen Eintrag verweisen außerdem Craig Wright, Gregory Maxwell.

DOC · 001GitHub — Pieter Wuille (sipa)Dokumentation DOC · 002BIP 32 — Hierarchical Deterministic WalletsDokumentation DOC · 003BIP 141 — Segregated WitnessDokumentation DOC · 004BIP 173 — Bech32Dokumentation DOC · 005BIP 350 — Bech32mDokumentation DOC · 006BIP 340 — Schnorr signaturesDokumentation DOC · 007BIP 341 — Taproot spending rulesDokumentation DOC · 008Bitcoin.org — FAQDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung