Bitcoin-Auszahlung basierend auf realen Ereignissen

Ich fange gerade an, Bitcoin-Scripting zu lernen. Kann jemand anhand eines realen Ereignisses erklären, wie man auszahlt?
Ich teste derzeit über die Befehlszeile mit bitcoind -regtest

Können Sie erklären, was Sie mit Bedingung meinen? Wenn ich ein normales Transaktionsskript verwende , enthält es zwei bedingte Anweisungen: OP_EQUALVERIFYund OP_CHECKSIG.
In der einfachsten Form, wenn eine Bedingung erfüllt ist, indem ein externes "Orakel" überprüft wird, dann zahlen Sie aus, wenn nicht, zahlen Sie nicht und fahren Sie mit der Überprüfung fort, bis die Bedingung erfüllt ist.
Es gibt keinen - das ist Absicht. Wenn es ein externes Orakel zulässt, könnte dieses Orakel einem Teil des Netzwerks mitteilen, dass die Transaktion gültig ist, und einem anderen mitteilen, dass die Transaktion ungültig ist.
Wie würde man also ein bedingtes Skript angehen, das auf einem realen Ereignis beruht, um eine Auszahlung auszulösen?
Lassen Sie einen vertrauenswürdigen Server das reale Ereignis überwachen und veranlassen Sie ihn dann, die Zahlung zu senden, wenn es passiert.
@NickODell Das scheint ein guter Anfang für eine Antwort zu sein. :)
Ich warte wie ein Schulmädchen auf die Antwort von Murphy
Sie könnten einen Dienst wie ifttt oder tasker verwenden, um die BitCoin-API mit einem realen Ereignisüberwachungsdienst zu verknüpfen.

Antworten (1)

Bitcoin kann das Ergebnis realer Ereignisse nicht direkt überprüfen. Es ist jedoch möglich, bedingte Geschäfte mit Hilfe Dritter zu tätigen. Dies kann mit Multisignatur-Adressen erreicht werden. Eine Multisignatur-Adresse ist eine Adresse, die von mehreren verschiedenen Personen verwaltet wird. Um das Geld von einer solchen Adresse auszugeben, sind Unterschriften von einer bestimmten Anzahl dieser Personen erforderlich. Um beispielsweise von einer 2-von-3-Multisignaturadresse auszugeben, müssen sich mindestens zwei der drei Eigentümer auf eine Transaktion einigen.

Wie kann dies verwendet werden, um bedingte Zahlungen zu leisten? Nun, es gibt drei Parteien: den Sender, den Empfänger und die Partei, die den Ausgang des Ereignisses bestimmt, die wir das Orakel nennen. Das Orakel liefert einen öffentlichen Schlüssel, der dem Ereignis entspricht, das die Bedingung für die Zahlung ist. Wenn das Ereignis eintritt, würde das Orakel den entsprechenden privaten Schlüssel preisgeben, sodass jeder ihn zum Erstellen von Signaturen verwenden könnte.

Nehmen wir nun an, dass der Absender sein Geld an eine 2-von-3-Multisignaturadresse sendet, wobei die Eigentümer er selbst, der Empfänger und der vom Orakel bereitgestellte öffentliche Schlüssel sind. Bis das Orakel seinen privaten Schlüssel preisgibt, kann der Empfänger das Geld nur mit Hilfe des Senders ausgeben. Anschließend kann der Empfänger den von Orakel offenbarten Schlüssel verwenden, um das Geld nach Belieben auszugeben.

Dieses Schema weist jedoch einige Probleme auf. Erstens, wenn das Ereignis nicht eintritt, kann der Absender sein Geld nur mit Hilfe des Empfängers zurückerhalten. Zweitens, wenn das Ereignis eintritt, kann der Absender sein Geld zurücknehmen, wenn der Empfänger nicht schnell genug ist, um es zuerst zu bewegen. Das erste Problem kann gelöst werden, indem der Empfänger eine Transaktion unterzeichnet, die Geld an den Absender zurückgibt, bevor der Absender die erste Transaktion rundsendet. Hier ist ein Beispiel dafür, wie diese Funktion verwendet werden kann. Das zweite Problem kann durch die Verwendung eines komplexeren Skripts als 2-von-3 gelöst werden. Beispielsweise ist es möglich, ein Skript zu erstellen, das das Geld von Sender + Empfänger und Empfänger + Orakel ausgeben lässt, aber nicht von Sender + Orakel.

Übrigens, als ich zu dieser Frage recherchierte, fand ich eine tatsächliche Website , die anbietet, private Schlüssel basierend auf dem Ergebnis realer Ereignisse offenzulegen.