PSBT v2

Anna und Jan möchten gemeinsam eine Rechnung bezahlen. Beide steuern eigene Mittel bei und fügen ihre Signatur auf dem eigenen Gerät hinzu. Sie müssen einen übereinstimmenden Entwurf austauschen, nicht ihre privaten Schlüssel. Ein privater Schlüssel ist eine geheime Zahl, mit der eine Wallet eine digitale Signatur zur Freigabe einer Ausgabe erzeugt. Für den Austausch des Entwurfs dient PSBT als Arbeitsmappe mit der Transaktion und ergänzenden Informationen. Eingänge verweisen auf frühere Beträge, die ausgegeben werden; Ausgänge bestimmen neue Beträge und deren spätere Ausgabebedingungen. Im ursprünglichen PSBT v0 liegt dieses Gerüst als feste globale unsignierte Transaktion vor. Bei v2 lassen sich Ein- und Ausgänge nach den entsprechenden Regeln schrittweise ergänzen. Der Vorteil ist die gemeinsame Erstellung, nicht die Freiheit, bereits Signiertes beliebig umzuschreiben. [1] [2]

Anna muss nicht jedes technische Feld lesen. Auf einem vertrauenswürdigen Signiergerät sollte sie aber Empfänger, Betrag, Gebühr und gegebenenfalls das Wechselgeld an die eigene Wallet prüfen. Gerade Letzteres kann leicht untergehen: Ein fremder Ausgang darf nicht für eigenes Wechselgeld gehalten werden. Das Gerät muss die UTXO-Unterlagen prüfen, also Informationen über noch nicht ausgegebene Ausgänge, und ihre Bedingungen mit dem Signierauftrag abgleichen. Ein Schlüsselableitungspfad beschreibt, wie die Wallet aus ihrem Hauptschlüssel einen bestimmten Schlüssel ableitet. Die bloße Angabe dieses Pfads beweist kein Eigentum. Das Signiergerät muss auch SIGHASH richtig auswerten: Diese Einstellung legt fest, welche Teile der Transaktion die Signatur schützt. Zum Signieren gehören weder ein privater Schlüssel noch die Seed Phrase, die Sicherungswörter der Wallet, in die weitergegebene Datei. [2] [4]

Die Angabe „PSBT-Unterstützung“ auf einem Gerät oder in einer App belegt noch keine Unterstützung für v2. Entscheidend ist der gesamte Ablauf: Erstellen, Importieren, Signieren und Zurückgeben des Ergebnisses zwischen den konkreten Programmen und Geräten. PSBT v0 und v2 sind nicht unmittelbar austauschbar. Für die Umwandlung in v0 muss eine unsignierte Transaktion erstellt werden; außerdem sind die Felder an die Regeln dieser Version anzupassen. Eine andere Versionszahl genügt nicht. Auch Taproot, eine neuere Art, Ausgabebedingungen von Bitcoin-Ausgängen festzulegen, ist nicht dasselbe wie v2. BIP 371 beschreibt die zugehörigen Signierdaten für beide PSBT-Versionen. Ein kleiner Test des ganzen Ablaufs prüft die Kompatibilität dieser Zusammenstellung, nicht die Richtigkeit jeder späteren Zahlung. [1] [3]

Die Version des Dateiformats und die Version der Bitcoin-Transaktion bedeuten unterschiedliche Dinge. Bei v2 muss PSBT_GLOBAL_VERSION den Wert 2 enthalten, während das alte Feld PSBT_GLOBAL_UNSIGNED_TX fehlen muss. Das getrennte Pflichtfeld PSBT_GLOBAL_TX_VERSION bestimmt die Version der Transaktion selbst. Auch die Anzahl der Eingänge und die Anzahl der Ausgänge müssen angegeben werden. So stehen die Informationen direkt beim jeweiligen Eintrag, statt dass das Programm zusätzlich in einem gemeinsamen Transaktionsgerüst suchen muss. Überlässt der Ersteller anderen Beteiligten den weiteren Aufbau, verlangt BIP 370 passende Änderungskennzeichen und eine Transaktionsversion von mindestens 2. Es handelt sich weiterhin um ein Arbeitsformat, nicht um neue Konsensregeln des Netzwerks. [1]

Jeder Eingang benötigt die TXID, die Kennung der vorherigen Transaktion, sowie den Index des daraus ausgegebenen Ausgangs. Die TXID allein reicht nicht, denn eine Transaktion kann mehrere Ausgänge haben. Jeder neue Ausgang enthält einen Betrag in satoshi, den kleinsten Bitcoin-Einheiten, und scriptPubKey, das Skript mit seinen Ausgabebedingungen. Beim Hinzufügen eines Eintrags muss auch dessen globale Anzahl angepasst werden. Das optionale Feld sequence enthält einen weiteren Steuerwert des Eingangs; fehlt es, wird 0xffffffff verwendet. Diese Konstruktionsdaten beschreiben den Aufbau der Transaktion. Sie ersetzen aber nicht die Angaben zu Wert und Ausgabebedingungen der verwendeten UTXO, die das Gerät zur sicheren Prüfung von Signatur und Gebühr braucht. [1]

Angenommen, Jan möchte einen weiteren Eingang hinzufügen. Das Programm darf nicht schon deshalb von einer Erlaubnis ausgehen, weil ihm die Datei vorliegt. In PSBT_GLOBAL_TX_MODIFIABLE kennzeichnet Bit 0 mögliche Änderungen an Eingängen und Bit 1 mögliche Änderungen an Ausgängen. Bit 2 weist auf eine SIGHASH_SINGLE-Signatur hin, die einen Eingang mit dem Ausgang an der entsprechenden Position verknüpft. Diese Paarung muss auch beim Einfügen weiterer Einträge erhalten bleiben. Der Ersteller prüft daher die tatsächlichen Signaturen und ihre Einschränkungen. Die Kennzeichen informieren die zusammenarbeitenden Programme; sie umgehen keine kryptografische Signatur und machen eine ungültige Änderung nicht gültig. [1]

Manche Eingänge verlangen, dass eine Transaktion erst nach einer bestimmten Blockhöhe oder Zeitgrenze verwendbar ist. Ein Block ist eine Gruppe von Transaktionen in der gemeinsamen Historie des Netzwerks; seine Höhe bezeichnet seine Position in der Kette. Das gemeinsame Feld nLockTime muss einen Anforderungstyp verwenden, der mit allen Eingängen vereinbar ist. Gewählt wird der höchste erforderliche Wert dieses Typs; sind beide Typen möglich, hat die Blockhöhe Vorrang. Höhe und Zeit lassen sich daher nicht einfach wie zwei gewöhnliche Zahlen vergleichen. Ohne Anforderungen der Eingänge gilt der globale Ersatzwert, andernfalls 0, wenn auch dieser fehlt. Ein Eingang mit unvereinbarer Anforderung darf nicht ergänzt werden. Existieren schon Signaturen, darf ein neuer Eingang zudem den berechneten nLockTime-Wert nicht ändern. Diese Felder allein gewährleisten nicht die Einhaltung sämtlicher Zeitsperrenregeln. [1]

Jede Signatur schränkt weitere Änderungen ein. Nach BIP 370 muss der Signierende Änderungen an Eingängen ohne SIGHASH_ANYONECANPAY und Änderungen an Ausgängen ohne SIGHASH_NONE deaktivieren; bei SIGHASH_SINGLE hält er die erforderliche Paarung fest. Diese Namen bezeichnen unterschiedliche Schutzbereiche einer Signatur, keine Schalter zum wahllosen Ausprobieren. Sind alle Eingänge bereit, setzt die Finalisierung die nötigen Signaturdaten zusammen; ein Extraktor erstellt aus den Feldern die Transaktion im Netzwerkformat. Erst das Senden ermöglicht es den Knoten, sie zu prüfen, und einem Miner, sie in einen Block aufzunehmen. Anna und Jan unterscheiden deshalb Entwurf, signiertes Ergebnis und bestätigte Zahlung. Die bloße Weitergabe eines PSBT stellt weder eine Signierung noch eine Bestätigung dar. [1] [2] [4]