Gregory Maxwell

Maxwells Arbeit verbindet Bitcoin-Entwicklung mit Privatsphäre und Sicherheit. Er gründete Blockstream mit und war dort CTO, also technischer Leiter. Am 19. Januar 2018 teilte die Firma mit, dass er diese Position verlassen hatte, um sich auf Bitcoin zu konzentrieren. Das ist das Datum der Mitteilung, kein Beleg für den genauen Tag seines Ausscheidens. Auch eine heutige Beschäftigung lässt sich daraus nicht ableiten. Hier sind die Probleme, an denen er arbeitete, wichtiger als ein Amtstitel. [1]

Stellen Sie sich vor, mehrere Menschen fassen ihre Zahlungen in einer Transaktion zusammen. Jeder bringt eigene Inputs ein, also früher erhaltene Coins, die nun ausgegeben werden, und genehmigt ihre Verwendung mit seiner Signatur. Allein aus der gemeinsamen Transaktion lässt sich deshalb kein gemeinsamer Eigentümer sicher ableiten. Unter dem Namen gmaxwell erläuterte Maxwell CoinJoin am 22. August 2013. Er erwähnte ausdrücklich frühere begrenzte Anwendungen. Eine Änderung der Bitcoin-Protokollregeln war dafür nicht nötig. [2]

Wie einigen sich die Beteiligten darauf, was sie signieren? Ein Koordinator kann einen einfachen CoinJoin zusammenstellen. Jeder prüft aber zuerst seinen Output: wohin seine Mittel gehen und in welcher Höhe. Erst dann signiert er seine Inputs. Der Koordinator erhält dadurch keine freie Verfügung über die Coins. In einer einfachen Umsetzung kann er dennoch wissen, welche Inputs zu welchen Outputs gehören. Verweigert ein Teilnehmer die Signatur, kann außerdem die ganze Runde scheitern. Diebstahlschutz, Verfügbarkeit und Privatsphäre sind unterschiedliche Eigenschaften. [2]

Gewöhnliche Bitcoin-Transaktionen zeigen Beträge öffentlich. Confidential Transactions lösen ein anderes Problem als das Zusammenfassen von Zahlungen: Sie verbergen Beträge in kryptografischen Commitments. Diese legen einen Wert fest, ohne ihn zu verraten, und erlauben zugleich die Prüfung von Summen. Maxwells Darstellung in Elements baut auf einem Vorschlag von Adam Back aus dem Jahr 2013 auf. Der Einsatz in Elements bedeutet nicht, dass diese Funktion im Bitcoin-Basisnetz eingeführt wurde. Verborgene Beträge verbergen außerdem nicht automatisch den Transaktionsgraphen, also die Verbindungen zwischen Zahlungen. [3]

Rechnerisch gilt 10 = 11 + (-1). Als Übertragungsmodell ohne Gebühren zeigt das ein Problem: Die Summe stimmt, aber ein positiver Output übersteigt den Ausgangswert und wird durch einen unsinnigen negativen Output ausgeglichen. Bei Confidential Transactions kann ein modularer Überlauf ähnlich wirken, wenn die Rechnung an der Grenze des Zahlensystems wieder von vorn beginnt. Deshalb braucht es einen Bereichsnachweis, einen range proof. Er bestätigt, dass der verborgene Betrag im erlaubten Intervall liegt, ohne seinen genauen Wert zu zeigen. Datenschutz darf keine Erzeugung zusätzlichen Geldes ermöglichen. [3]

Warum zusätzliche Ausgabebedingungen veröffentlichen, wenn sich alle einigen und diese Bedingungen gar nicht gebraucht werden? Maxwells Taproot-Vorschlag vom 23. Januar 2018 zeigte, wie eine gemeinsame Signatur die Existenz alternativer Bedingungen verbergen kann. Wenn die Beteiligten zusammenarbeiten, kann eine komplexere Vereinbarung wie eine gewöhnliche, durch einen Schlüssel autorisierte Zahlung aussehen. Das Datum des Beitrags ist aber nicht das Aktivierungsdatum im Netzwerk. Zwischen Idee und Einführung liegen Diskussion, genaue Regeln und deren Annahme. [4]

Die fertige Spezifikation BIP 341, ein öffentliches technisches Dokument zu den Taproot-Regeln, nennt Pieter Wuille, Jonas Nick und Anthony Towns als Autoren. Der Schlüsselpfad kann eine Signatur nutzen, ohne die Existenz eines alternativen Skripts zu zeigen. Ein Skript ist ein Programm mit Ausgabebedingungen. Wird der Skriptpfad verwendet, werden das gewählte Programm und sein Zugehörigkeitsnachweis offengelegt. Das schmälert Maxwells ursprüngliche Idee nicht, macht ihn aber auch nicht zum alleinigen Autor der endgültigen Regeln. [5]

Beim Bezahlen muss auch die Adresse richtig geschrieben sein. Pieter Wuille und Greg Maxwell sind die Autoren von BIP 173, das Bech32 für native SegWit-Adressen beschreibt. Seine Prüfsumme besteht aus Zeichen, die Fehler in der Kodierung erkennen helfen. Sie bestätigt weder die Identität des Empfängers noch den Besitz des privaten Schlüssels. Eine gültige, aber ausgetauschte Adresse kann die Prüfung bestehen. Bech32 behandelt somit ein anderes Problem als CoinJoin oder verborgene Beträge; diese Vorteile sind nicht austauschbar. [6]