Можно ли использовать биткойн-скрипты для атак двойного расходования?

Стандартная транзакция Биткойн вносит монеты на адрес, а затем, используя язык сценариев Биткойн, заявляет, что тот, кто хочет потратить этот вывод, должен обладать закрытым ключом, соответствующим этому адресу.

Однако можно отклониться от этого базового шаблона для создания более сложных транзакций, в которых должны быть выполнены другие условия, чтобы можно было потратить вывод транзакции.

Можно ли создать транзакцию, в которой сумма зачисляется на адрес, но потратить ее может только владелец другого закрытого ключа? Я не эксперт по биткойн-скриптам, но это выглядит как минимум возможным.

В этом случае можно ли использовать такую ​​созданную транзакцию для проведения атаки двойного расходования средств, когда адрес A отправляет сумму X на адрес B, но после завершения транзакции адрес A сохраняет право собственности на сумму и может отправить ее куда-либо еще, в то время как адрес B фактически ничего не может с этим поделать, даже если сумма будет зачислена на его баланс?

Как стандартный кошелек отнесется к такой транзакции? Будет ли он даже распознавать, что происходит что-то странное, или будет слепо отображать, что X BTC вошел в адрес B, независимо от сценария транзакции?


Редактировать:

Извините, меня ввело в заблуждение то, как такие сайты, как blockchain.info, отображают транзакции: транзакция на самом деле не содержит никакого «адреса выхода», она содержит только выходы, в которых указаны условия, необходимые для их траты; «выходной адрес» вычисляется путем проверки того, подпись какого адреса запрашивается выходным сценарием; таким образом, невозможно «отправить деньги на адрес B», фактически не помещая адрес B в выходной скрипт.

Тем не менее, остается вопрос: можно ли создать транзакцию, чтобы обмануть кошелек и заставить его сообщить пользователю: «Я получил X BTC», в то время как кто-то другой может получить сумму, используя другой закрытый ключ?

Обратите внимание, что транзакция в том виде, в каком я ее описал, составлена ​​таким образом, что B вообще не имеет права тратить сумму; вместо этого более сложная транзакция может позволить потратить ее как B, так и A.
Я думал, что ключ генерируется для каждой отдельной транзакции, поэтому, если A или B не тратят эту сумму, она должна быть совершенно другой и списываться с исходного счета.
Хорошо, это не сработает (см. редактирование). Но, может быть, что-то еще...

Ответы (2)

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

Может быть, вы могли бы создать нестандартную транзакцию и сказать людям, что она дает владельцу адреса B разрешение потратить ее, но если люди внимательно изучат транзакцию, они смогут сказать, что это действительно адрес C (а не B)». с владельцем, который может потратить его. Обойти это невозможно: вывод транзакции является общедоступным, как и реализация того, как она работает.

Итак, если вопрос: можно ли обмануть программное обеспечение X нестандартной транзакцией? Возможно, это будет зависеть от обнаружения ошибки (или другой далеко не идеальной ситуации) в рассматриваемом программном обеспечении. (например, если вы создадите транзакцию, которая может быть потрачена по адресу B или C, возможно, кошелек, владеющий B, скажет, что у него есть баланс, и если он не переведет его снова, прежде чем вы это сделаете, тогда вы можете «украсть обратно "деньги таким образом) Однако я бы отнесся к любым нестандартным сделкам как к весьма подозрительным.

Согласен (см. редактирование). Однако остается вопрос: как клиенты реагируют на нестандартные сделки? Как эталонный клиент переходит от «скрипт вывода транзакции» к «эй, вы только что получили 42 BTC»? Можно ли его обмануть чем-то подобным?

Нет, стандартный клиент этим не обманешь. Если он не понимает скрипт полностью (т.е. это нестандартный скрипт), он не пытается разобрать его частично или еще что-то. Процедура проста: если клиент не может полностью понять сценарий, он просто игнорируется. Период.

Любая ссылка на это? Какие типы транзакций считаются «стандартными»? Кто решает, является ли транзакция стандартной? Как вообще можно замайнить нестандартную транзакцию в блокчейн, если эталонное ПО ее просто игнорирует?
Есть протокол, а есть эталонная реализация и другие реализации. Протокол стабилен, а его реализации — нет, и некоторые функции в некоторых клиентах внедряются быстрее. То же самое и с политикой использования trx — разные реализации имеют немного разные правила, когда дело доходит до решений о доверии trx. Что такое «стандартный» сценарий, зависит от клиента, но обычно это сценарий, для которого требуется действительный открытый ключ и подпись. Больше информации здесь .
см. github.com/bitcoin/bitcoin/blob/… (решатель функций) — даже если вы не знаете программирования, эти четыре строки должны быть достаточно понятными, и они содержат четыре стандартные транзакции. В будущих версиях bitcoind любые другие транзакции будут стандартными ( bitcoin.stackexchange.com/questions/28181/… ), но, тем не менее, клиенты/кошельки просматривают всю транзакцию для вычисления биткойн-адреса.