Normalerweise benötigt jemand, der eine Multisig-Transaktion signiert, neben seinem eigenen privaten Schlüssel auch das Einlöseskript oder alle öffentlichen Schlüssel, die für die Erstellung des Einlöseskripts verwendet wurden.
Nein, dachte ich, ist dies auch für eine 2of2-Multisig-Adresse erforderlich. Nehmen wir an, die beiden Parteien sind Alice und Bob. Alice und Bob generieren beide ein Schlüsselpaar. Bob sendet seinen öffentlichen Schlüssel an Alice und sie erstellt das Einlösungsskript. Jetzt kennt Alice beide öffentlichen Schlüssel, aber Bob kennt nur seinen öffentlichen Schlüssel. Alice erstellt nun eine Transaktion, die das Geld ausgibt, und signiert sie mit ihrem privaten Schlüssel. Sie sendet diese rohe, halb unterzeichnete Transaktion an Bob. So weit so normal. Aber normalerweise benötigt Bob hier das Einlöseskript oder beide öffentlichen Schlüssel, um das Einlöseskript selbst zu generieren. Ich habe mich jetzt gefragt: Beim Signieren der Transaktion fügt Alice ihre Signatur zur Transaktion hinzu und auch ihren öffentlichen Schlüssel, damit die Signatur verifiziert werden kann. Bob könnte also Alices öffentlichen Schlüssel aus der Rohtransaktion extrahieren, die er gerade erhalten hat, und damit das Einlösungsskript selbst generieren?
Daher meine Frage: Stimmt das? Und wenn ja, bedeutet das, dass unabhängig davon, ob es sich um 2of2 oder 4of4 handelt, der letzte Unterzeichner immer das Einlösungsskript aus der empfangenen Rohtransaktion neu erstellen kann?
Es ist, irgendwie, aber einige Überlegungen müssen berücksichtigt werden.
Es gibt zwei Möglichkeiten, eine Multisig-Transaktion zu erstellen: Pay-to-Multisig oder ein Pay-to-Script-Hash , der ein Pay-to-Multisig kapselt. Wie Sie die Frage stellen, vermute ich, dass Sie sich auf letzteres beziehen. Ich werde Ihnen jedoch für alle Fälle beide Antworten geben.
Pay-to-Script-Hash (P2SH)
Die Skripte eines 2-3 Multisig, das in einer P2SH-Transaktion gekapselt ist, sehen folgendermaßen aus:
ScriptSig: OP_0 [Sig 1] [Sig 2] OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG
ScriptPubKey: OP_HASH160 <ScriptHash> OP_EQUAL
Wie Sie bereits erwähnt haben, kann Bob das Skript neu erstellen, da der ScriptPubKey nur den Hash der generierten scriptSig benötigt und er über alle Informationen verfügt. Allerdings kommt es auf die Reihenfolge an. In diesem Fall (ein 2-3 Multisig) hätte Alice das Skript auf sechs verschiedene Arten erstellen können:
Dies hat zwei Konsequenzen, die einfachste ist, dass der Hash unterschiedlich ist, wenn das Skript nicht auf die gleiche Weise erstellt wird. Darüber hinaus gibt die Reihenfolge, in der die Schlüssel bereitgestellt werden, an, wie die Signaturen bereitgestellt werden sollten, dh Signaturen und Schlüssel müssen in derselben Reihenfolge bereitgestellt werden.
z.B:
ScriptSig: OP_0 [Sig 2] [Sig 1] OP_2 [PK 2][PK 3][PK 1] OP_3 OP_CHECKMULTISIG
Dann hat Alice in einem nm-Multisig n!Möglichkeiten, die öffentlichen Schlüssel zu arrangieren. Wenn sie nicht in der richtigen Reihenfolge bereitgestellt werden, schlägt die Auswertung des Skripts fehl, wodurch die Transaktion ungültig wird.
Pay-to-Multisig
Im Fall von Pay-to-Multisig ist die Lösung aufgrund der Informationen, die jedes Skript speichert, viel einfacher. Unter Verwendung desselben 2-3-Multisig-Beispiels werden die resultierenden Skripte wie folgt aussehen:
ScriptSig: OP_0 [Sig 1] [Sig 2]
ScriptPubKey: OP_2 [PK 1][PK 2][PK 3] OP_3 OP_CHECKMULTISIG
In diesem Fall wissen nicht nur letztere, sondern alle beteiligten Parteien, wie die ScriptSig erstellt wird, da die Erstellung des ScripPubKey von der vorherigen Transaktion aus zugänglich ist.
Schritt m
Jetzt kennt Alice beide öffentlichen Schlüssel, aber Bob kennt nur seinen öffentlichen Schlüssel.
Schritt N
Alice erstellt nun eine Transaktion, die das Geld ausgibt, und signiert sie mit ihrem privaten Schlüssel.
Es ist nicht möglich, direkt von step Mbis zu gehen, step Nda danach noch nichts ausgegeben werden sollstep M
Zunächst einmal sollte Alice eine 2-von-2-Multisig-Adresse erstellen und jemand sollte sie finanzieren. Nach der Finanzierung müssen sie die Ausgabentransaktion erstellen und unterzeichnen.
Sie sendet diese rohe, halb unterzeichnete Transaktion an Bob.
Das Versenden von unsignierten oder teilweise signierten Transaktionen war schon immer schwierig und implementierungsspezifisch. Dies ist das Problem, zu dessen Lösung Partially Signed Bitcoin Transactions entwickelt wurde. Siehe Motivationsabschnitt für BIP 174 . Speziell für Ihre Frage sollte das PSBT das Einlöseskript für alle P2SH-Eingaben enthalten.
jneubery
OP_CHECKSIGs solltenOP_CHECKMULTISIGin dieser Antwort s sein.sr-gi