Какая связь между scriptSig и scriptPubKey?

Сценарий: A отправляет 1 BTC игроку B.

scriptSig появляется во входном скрипте.

scriptSig = <sig> <pubKey>
  1. Здесь открытый ключ — это открытый ключ отправителя А. (это открытый ключ, соответствующий его биткойн-адресу, на котором есть какая-то неизрасходованная транзакция).

Что такое sig часть scriptSig?

скриптPubKey

scriptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

pubKeyHash = Хэш открытого ключа получателя (в нашем случае B).

  1. Отправитель (А) имеет только биткойн-адрес получателя (Б), так как же он может получить pubKeyHash со своего биткойн-адреса?

Теперь, это мое понимание до сих пор:

  1. Входной сценарий несет информацию о «предыдущей транзакции» отправителя и указывает на соответствующую «выходную» часть «предыдущей транзакции» с помощью индекса. Результатом предыдущей транзакции является общий доступный баланс отправителя (A), который может быть использован для отправки биткойнов получателю (B).

  2. Этот входной скрипт также используется для проверки того, что отправитель (А) является фактическим владельцем биткойнов, хранящихся в указанном выходе предыдущей транзакции.

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

Вопросы:

  1. Открытый ключ в scriptSig отличается от открытого ключа в scriptPubKey?

  2. Как подписанная информация отправителя может быть проверена получателем, если они не используют один и тот же открытый ключ?

  3. Я попытался понять пример, приведенный в вики, который показывает, как скрипт выполняется на основе стека, но не смог его понять.

У меня есть еще несколько вопросов, но я думаю, что задам их в другом вопросе, а не здесь.

Спасибо.

Вы можете посмотреть видео Мэтта Томаса на YouTube, он блестяще объясняет, youtube.com/watch?v=ir4dDCJhdB4 .

Ответы (6)

Во-первых, два совпадающих сценария используются в двух разных транзакциях, один из которых переводит средства на адрес (транзакция A ), а другой тратит эти средства (транзакция B ). Создается scriptPubKeyпользователем, который создает транзакцию A . По сути, он добавляет условие претензии к создаваемому результату. Пользователь может требовать и, таким образом, тратить биткойны, связанные с выводом, только если он может доказать, что он владеет выводом.

Здесь в игру вступает транзакция B и the . scriptSigПредположим, что пользователь хочет куда-то отправить средства. Он создает новую транзакцию и добавляет к ней выходы, пока не наберет достаточно, чтобы покрыть желаемую сумму. Теперь он должен доказать, что он владеет этими выводами, что он и делает, предоставляя вывод, необходимый для их получения, т. е. открытый ключ, соответствующий адресу и подписям, совпадающий с закрытым ключом.

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

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

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

@cdecker Зачем отправителю в транзакции B вообще нужно сравнивать HASH160 публичного ключа с pubKeyHash? Разве подписи, которая, если она верна, гарантирует, что отправитель имеет доступ к закрытому ключу адреса вывода, с которого он отправляет, недостаточно, чтобы убедиться, что он может отправлять с этого вывода? Представляется ненужным предоставлять открытый ключ и проверять совпадения его хэшей, поскольку открытый ключ можно быстро получить из закрытого ключа.
При финансировании отправителя Транзакции Б эмитент Транзакции А не знает открытого ключа, только его хеш, который закодирован в адресе. Создатель транзакции B должен показать открытый ключ, показать, что он действительно соответствует хэшу в адресе, а затем предоставить действительную подпись, используя его. Если бы она не включила открытый ключ и не показала, что он соответствует хешу, то мы упустили бы важную часть информации, т. е. открытый ключ, и не смогли бы проверить подпись.
Я предполагаю, что во втором абзаце «Он создает новую транзакцию и добавляет к ней выходные данные», должно быть «добавляет к ней входные данные». Пользователь будет добавлять входы в транзакцию
Я пытался вообще не вводить входные данные, поскольку они являются просто ссылками на ранее созданные выходные данные, но это может сбивать с толку, вы правы.
Может быть, немного поздно, но разве второе предложение в последнем абзаце не должно быть «Он требует одного ввода, предоставляя ..»?

У меня тоже был тот же вопрос, и я потратил целую вечность, пытаясь понять его, и, наконец, взломал его.

«Отправитель (А) имеет только биткойн-адрес получателя (Б), так как же он может получить pubKeyHash со своего биткойн-адреса?»

Суть в том, что отправителю (А) не нужно получать pubKeyHash со «своего» биткойн-адреса, потому что это не имеет значения. (я тоже о том же подумал!)

Сначала подумайте о scriptPubKey . A создает это с биткойн-адресом B вместо <pubKeyHash>. Это работа А сделана. А сказал следующее: «1 BTC теперь принадлежит B, но… только если B сможет доказать, что он является истинным владельцем биткойн-адреса, который B предоставил мне». Теперь уберите А с картинки.

Приходит B и видит в своем кошельке сумму в 1 BTC. Так что технически B «владеет» им. Но для того, чтобы B мог их потратить, то есть отправить кому-то другому, B должен доказать, что биткойн-адрес, который он дал A, действительно принадлежит ему. Вот тут-то и появляется scriptSig . Так что <sig> <pubKey>ответственность лежит на B, и B все равно знает всю эту информацию.

Прочитав множество статей об этом, документация разработчика объясняет это лучше всего. https://bitcoin.org/en/developer-guide#transactions Вам просто нужно медленно прочитать его несколько раз.

Документация для разработчиков также отвечает на ваш другой вопрос: «Что такое sig часть scriptSig?»

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

Этот ответ менее запутан, чем принятый ответ.

Пожалуйста, ознакомьтесь с документом разработчика. Это намного яснее. https://bitcoin.org/en/developer-guide#transactions

Я согласен, документ разработчика имеет более четкое объяснение.
scriptSig = <sig> <pubKey>

Что такое sig часть scriptSig?

Это подпись, сделанная А с его закрытым ключом, содержимого транзакции, которую он создает, за исключением scriptSigчасти (чтобы не быть рекурсивной). Он сделан из <hash of the transaction from which an output is being used> <the index of this output in that transaction> <pubKey> <the current transaction output = <scriptPubKey> <1 BTC> >.

sciptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  1. Отправитель (А) имеет только биткойн-адрес получателя (Б), так как же он может получить pubKeyHash со своего биткойн-адреса?

Вы можете найти <pubKeyHash>from по адресу, потому что заключительные операции создания адреса не запутывают ввод. Это просто кодировка base58 pubKeyHash, дополненная некоторыми данными, т . е. address = base58_encode(<pubKeyHash> || <padding>)таким образом pubKeyHash = base58_decode(address) ^^ <padding>.

Ваше понимание верно, за исключением части:

  1. Входной сценарий несет информацию о «предыдущей транзакции» отправителя и указывает на соответствующую «выходную» часть «предыдущей транзакции» с помощью индекса. Результатом предыдущей транзакции является общий доступный баланс отправителя (A), который может быть использован для отправки биткойнов получателю (B).

Сценарий ввода — scriptSig и не содержит ссылки на расходуемый вывод. Эта информация находится на входе текущей транзакции, но формально отсутствует в сценарии разблокировки.

Вопросы:

  1. Открытый ключ в scriptSig отличается от открытого ключа в scriptPubKey?

Да они разные, т pubKeyHash = ripemd160(sha256(pubKey)).

  1. Как подписанная информация отправителя может быть проверена получателем, если они не используют один и тот же открытый ключ?

scriptSig включается во входные данные транзакции (вместе с хэшем предыдущей транзакции и индексом потраченных выходных данных), так что каждый имеет доступ к pubKey для проверки того, что <sig>он действителен против <pubKey>.

  1. Я попытался понять пример, приведенный в вики, который показывает, как скрипт выполняется на основе стека, но не справился.

Ну, я мало что мог бы объяснить иначе, чем любую другую документацию, если вы не предоставите здесь подробности.

Пусть будет 2 транзакции: транзакция A (coinbase) и транзакция B. ScriptPubkey- Чтобы заблокировать транзакцию А для открытого ключа. ScriptSig- Используется в транзакции B , чтобы разблокировать транзакцию A.

Поскольку транзакция A является coinbase (добытой майнером), не будет ScriptSig. ScriptPubkey транзакции A — это сценарий открытого ключа майнера (т. е. привязанный к открытому ключу майнера, поэтому в будущем он сможет разблокировать его с помощью своего закрытого ключа [то есть ScriptSig])

Майнер может потратить эту биткойн-транзакцию Алисе, предоставив ScriptSig (подписанный закрытым ключом майнера) на входе транзакции B. Помните, что открытый ключ майнера генерируется из его закрытого ключа, программа Биткойн может проверить ScriptPubkey. транзакции A из ScriptSig транзакции B, то, если транзакция B действительна, она будет добавлена ​​в блокчейн.

ScriptPubkey транзакции B будет открытым ключом Алисы, поэтому в будущем только Алиса сможет потратить этот биткойн, используя ScriptSig в транзакции C.

Простое и менее техническое объяснение для новичков: пусть Алиса будет отправителем, а Боб — получателем. Алиса создает ScriptPubKey, соответствующий закрытым ключам кошелька Боба. Затем она передает этот ScriptPubKey вместе с сатоши в сеть биткойнов, и сатоши начинают появляться в кошельке Боба в качестве баланса. Итак, ScriptPubKey действует как «замок».

Теперь, чтобы Боб мог потратить эти сатоши, он должен выполнить условия, которые Алиса разместила в ScriptPubKey. Поэтому он создает scriptSig (или сценарий подписи) как решение, удовлетворяющее условиям ScriptPubKey, чтобы тратить эти сатоши. Здесь scriptSig действует как ключи для блокировки ScriptPubKey.

Какая связь между scriptSig и scriptPubKey?
СпросиСетьПолитика конфиденциальности1y, 72v