Выплата биткойнов на основе реального события

Только начинаю изучать биткойн-скриптинг. Может кто-нибудь объяснить, как платить на основе какого-то реального события?
В настоящее время я тестирую из командной строки с помощью bitcoind -regtest

Не могли бы вы уточнить, что вы подразумеваете под условным? Когда я использую обычный сценарий транзакции , он включает два условных оператора: OP_EQUALVERIFYи OP_CHECKSIG.
В самой простой форме, если условие выполняется при проверке внешнего «оракула», то платите, если нет, то не платите и продолжайте проверять, пока условие не будет выполнено.
Его нет - это намеренно. Если бы он позволял внешнему оракулу, этот оракул мог бы сообщить одной части сети, что транзакция действительна, а другой — что транзакция недействительна.
Итак, как можно использовать условный сценарий, который полагается на событие из реальной жизни, чтобы вызвать выплату?
Пусть доверенный сервер отслеживает реальное событие, а затем отправляет платеж, когда это происходит.
@NickODell Кажется, это хорошее начало для ответа. :)
Я жду ответа Мерфи, как школьница.
Вы можете использовать такой сервис, как ifttt или Tasker, чтобы связать BitCoin API с реальной службой мониторинга событий.

Ответы (1)

Биткойн не может напрямую проверить исход реальных событий. Однако возможно совершение условных сделок с помощью третьих лиц. Это может быть достигнуто с помощью мультиподписных адресов. Адрес с мультиподписью — это адрес, который контролируется несколькими разными людьми. Чтобы потратить деньги с такого адреса, требуются подписи определенного количества этих людей. Например, чтобы потратить с адреса с мультиподписью 2 из 3, по крайней мере два из трех владельцев должны согласиться на транзакцию.

Как это можно использовать для осуществления условных платежей? Итак, есть три стороны: отправитель, получатель и сторона, определяющая исход события, которую мы будем называть оракулом. Оракул предоставляет открытый ключ, соответствующий событию, являющемуся условием платежа. Если событие произойдет, оракул раскроет соответствующий закрытый ключ, чтобы любой мог использовать его для подписи.

Теперь предположим, что отправитель отправляет свои деньги на адрес с мультиподписью 2 из 3, владельцем которого является он сам, получатель и открытый ключ, предоставленный оракулом. Пока оракул не раскроет свой закрытый ключ, получатель может потратить деньги только с помощью отправителя. После этого получатель может использовать ключ, раскрытый оракулом, чтобы потратить деньги по своему усмотрению.

Однако у этой схемы есть несколько проблем. Во-первых, если событие не происходит, отправитель может забрать свои деньги только при содействии получателя. Во-вторых, если событие действительно произойдет, отправитель может забрать свои деньги обратно, если получатель не достаточно быстр, чтобы перевести их первым. Первую проблему можно решить, если получатель подпишет транзакцию, возвращающую деньги отправителю, до того, как отправитель транслирует первую транзакцию. Вот пример того, как можно использовать эту функцию. Вторую проблему можно решить, используя более сложный сценарий, чем 2-из-3. Например, можно сделать скрипт, который позволяет тратить деньги отправителю+получателю и получателю+оракулу, но не отправителю+оракулу.

Кстати, изучая этот вопрос, я нашел реальный веб- сайт , который предлагает раскрывать закрытые ключи на основе результатов реальных событий.