Для меня номенклатура немного расстраивает. Я предпочитаю условие вывод сценарий и ввод сценарий. Поля scriptPubKey и scriptSig скрипты, они не должны содержать Публичный, подпись и т.д. Причину, они были названы так потому, что
как обычно выходной сценарий содержит открытый ключ, который «замки» средства, а сценарий ввода содержат подпись (или подпись и открытый ключ - это зависит, получит к тому, что в секунде), которая проверяет против открытого ключа предыдущих выходных сценариев. Это указывает тип, что это будет включено, но это не обязательно должно быть так.
Я на самом деле немного запутался о вашем примере сделки, поскольку открытые ключи не начинаются с 90. То, что вы нашли это сделка, которая проводит недавно добытые монеты https://www.blocktrail.com/BTC/tx/f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Вы можете увидеть на этой странице, что выходной сценарий заключается в следующем:
<публичный ключ> OP_CHECKSIG
Этот тип вывод сценария известен как сценарий плата к-Публичный - нет Публичного хэша здесь, и это потому, что адреса не всегда используются в сети. Обращайте к Публичному-хэш сохраняет конфиденциальность получателя, так как открытый ключ раскрывается известен, и адрес получателя короче открытого ключа.
Таким образом, глядя на сделку вы специально refered в вашей почте:
https://www.blocktrail.com/BTC/tx/5a4ebf66822b0b2d56bd9dc64ece0bc38ee7844a23ff1d7320a88c5fdb2ad3e2 который проводит эти новые минные монеты:
Единственный вход тратит заминированные монеты. Посмотрите на входной скрипт здесь - есть только одно поле, подпись. Это то, что меня смутило, потому что ты сказал, что открытый ключ есть клиент будет выполнять [scriptSig] [scriptPubKey], так что ваш скрипт работает так: [сиг] [Публичный] OP_CHECKSIG - с сиг и Публичный поставляются в качестве входных данных OP_CHECKSIG.
Теперь посмотрим, что ваш операции вывода сценария. Он отличается в том, что из добытых монет, он выглядит следующим образом:
OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG
Это очень отличается от первой сделки - это больше не будет платить к Публичному, но оплате за Публичным-хэш. Там нет открытого ключа выявлен, но вместо того, чтобы открытый ключ в настоящее время должен быть включен во входном скрипте.
[ScriptSig] [scriptPubKey]
[Сиг Публичных] [OP_DUP OP_HASH160 хэш OP_EQUALVERIFY OP_CHECKSIG]
... несколько шагов пройти в то время как сиг, Публичный выталкиваются, то Публичный дублируются, новая преобразуются в это хэш, подтвердили соответствие хеша, и хэш удаляются тогда.
сиг Публичных OP_CHECKSIG
Этот последний шаг такого же, как сделки с оплатой по-Публичной к клиенту, но на этот раз открытый ключ предоставляется в scriptSig вместо scriptPubKey. Именование надоедает, не так ли
Предыдущий f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6 Tx
- Владельцы открытого ключа: 04283338ffd784c198147f99aed2cc16709c90b1522e3b3637b312a6f9130e0eda7081e373a96d3
6be319710cd5c134aaffba81ff08650d7de8af332fe4d8cde20 (расположен в выходном сценарии)
- Владельцы общественного Хэш ключа: не известно! открытый ключ уже известен к тому времени, получатель имеет свои средства.
Ваш 5a4ebf66822b0b2d56bd9dc64ece0bc38ee7844a23ff1d7320a88c5fdb2ad3e2 Tx
- Владельцы открытого ключа: 04d4fb35c2cdb822644f1057e9bd07e3d3b0a36702662327ef4eb799eb219856d0fd884fce43082
b73424a3293837c5f94a478f7bc4ec4da82bfb7e0b43fb218cc
не известно до тех пор, пока пользователь не тратит от этого адреса - Владельцы открытого ключа хэша: 404371705fa9bd789a2fcd52d2c580b65d35549d
Re: Публичный и pubkeyHash
