Zunächst einmal verstehe ich, dass die Standardmethode zur Hinterlegung von Bitcoins ein P2SH mit einem 2-von-3-Multisig-Einlösungsskript ist. Ich möchte versuchen, die Hinterlegung auf folgende Weise durchzuführen:
Namen der 3 Beteiligten:
money sourceescrow agentmoney destinationEs sind 2 Transaktionen beteiligt:
escrow transaction: Das money sourcesendet Geld an ein benutzerdefiniertes Sperrskriptspending transaction: die escrow agentbewegt Gelder von der escrow transactionzu dermoney destinationMit diesen Eigenschaften hat der escrow agentdie vollständige Kontrolle über die Ausgaben der Gelder, ABER er escrow agentkann sie nur in den money destinationund nirgendwo anders verschieben. (dh escrow agentkann das Geld nicht stehlen)
Mir ist klar, dass das benutzerdefinierte Sperrskript von escrow transactionirgendwie auf die money destinationAdresse von verweisen und einen Mechanismus bereitstellen muss, damit dies funktioniert, wenn das escrow transactionSperrskript von entsperrt wird, es überprüft, ob die Transaktion, in der es verwendet wird, tatsächlich ist geht zum money destination.
Es scheint, dass man nicht direkt auf die Ausgabeadresse von verweisen kann, spending transactionwenn die spending transactionverifiziert wird. Die einzige Möglichkeit, die Ausgabeadresse Teil der Überprüfung zu haben, ist indirekt über CHECKSIG (da die zu signierenden Daten die Ausgabeadresse von enthalten spending transaction). Aber damit dies funktioniert, müssten wir die signieren spending transactionund diese Signatur einfügen die escrow transaction, aber das erzeugt eine zirkuläre Abhängigkeit: die escrow transactionenthält eine Signatur von die spending transactionden Hash von enthält escrow transaction(da die escrow transactioneine Eingabe für die ist spending transaction). Das wäre also unmöglich. Ich wünschte, es gäbe einen Hashtyp, der es Ihnen erlaubt, nur die Ausgabeseite der Transaktion und überhaupt nicht die Eingaben zu signieren.
Ich bin ziemlich neu bei Bitcoin, also übersehe ich vielleicht etwas. Aber es scheint, dass das Entwerfen einer Hinterlegung mit den Eigenschaften, die ich zu Beginn dieser Frage beschrieben habe, unmöglich wäre, und die einzige Möglichkeit, eine Hinterlegung durchzuführen, ist ein Standard-P2SH 2 von 3 Multisig.
Der Grund, warum ich kein Standard-Multisig machen möchte, ist, dass es auf vertrauenslose Weise funktioniert. der money sourceund money destinationmüssen ihre Adressen direkt austauschen (dh der escrow agentkann den anderen 2 Parteien die passenden Adressen nicht geben, weil er die falschen Adressen herausgeben könnte). Auf diese Weise kann der Treuhänder, wenn escrow agenter das TXN unterschreibt und es der anderen Partei zum Unterschreiben gibt, überprüfen, ob der Treuhandagent es unterschrieben hat, um an die richtige Stelle zu gelangen.
Ich möchte escrow agent, dass der Ansprechpartner für die anderen 2 Parteien ist, damit sie vor der Zusammenarbeit mit dem keinen Adressaustausch durchführen müssen, dem escrow agentaber trotzdem nicht vertrauen müssenescrow agent
Teilantwort (keine neue Lösung - ich habe lediglich das Mikrozahlungskanalprotokoll angepasst): Wenn Sie den Austausch öffentlicher Schlüssel zulassen, scheint mir eine Lösung zu sein:
sourcefinanziert eine Adresse A, die von sourceund kontrolliert wirdescrow sourceunterzeichnet Transaktion T teilweise, die A bis ausgibt destination. Dann sendet sie diese teilweise signierte Transaktion an escrow.Es liegt nun an escrowT zu unterzeichnen und auszustrahlen, damit dieser destinationdie Mittel erhält. Escrowkann die Gelder nicht anders ausgeben (z. B. stehlen), als es eine Mitunterzeichnung erfordern sourcewürde.
(Problem: Escrowkönnte entscheiden, die Gelder nicht zu unterzeichnen und zu "blockieren" (deshalb sind Rückerstattungstransaktionen in Zahlungskanälen enthalten). Gelöst, indem Escroweine Transaktion R teilweise unterzeichnet und an die Quelle gesendet wird, um die Gelder von A zurück sourcean t0 zu senden. Es Jetzt sourceschickt sie sich das Geld von A zurück. Ist das ein Problem? Nicht wirklich, wenn Transaktion R "zeitgesperrt" ist.)
Es scheint schwieriger, eine Lösung ohne den Austausch öffentlicher Schlüssel zu finden ... aber es ist ein bisschen seltsam, den Austausch öffentlicher Schlüssel zu verbieten.
Manfred Macx