Сегвит с мультиподписью

Я анализировал биткойн-транзакцию, которая работает как с Segwit, так и без Segwit для скриптов с мультиподписью. Вот транзакция: https://www.blockchain.com/en/btc/tx/80975cddebaa93aa21a6477c0d050685d6820fa1068a2731db0f39b535cbd369

Обратите внимание, что по индексам 0, 1 и 2 у нас есть скрипт разблокировки в файле scriptsig, а по индексу 3 он использует программу-свидетель. Никаких проблем до сих пор.

Что меня беспокоит, так это то, почему, когда я получаю скрипт погашения с индексами 0, 1 и 2 и выполняю ripemd60, sha256, создаю контрольную сумму и кодирую в base58, он генерирует публичный адрес, как мы можем видеть на экране blockchain.com. Но когда я делаю то же самое, используя сценарий погашения, который находится в разделе свидетелей, он возвращает мне совершенно другой адрес, почему это происходит?

Кроме того, что такое scriptSig на индексе 3? Как он генерируется?

Пример:

Выкупить скрипт индекса 0:

522102194e1b5671daff4edc82ce01589e7179a874f63d6e5157fa0def116acd2c3a522103a043861e123bc67ddcfcd887b167e7ff9d00702d1466524157cf3b28c7aca71b2102a49a62a9470a31ee51824f0ee859b0534a4f555c0e2d7a9d9915d6986bfc200453ae

Адрес, сгенерированный из индекса 0 с помощью моего скрипта:

3JUJgXbB1WpDEJprE8wP8vEXtba36dAYbk

Это то же самое, что и транзакция.

Погасить скрипт индекса 3 (Segwit):

5221021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe2103bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38210280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c6553ae

Адрес, сгенерированный из индекса 3 с помощью моего скрипта:

36aKiVksQRLKwByBYVz3KwquFcvHZkwroP

Адрес транзакции, восстановленный с blockchain.com

3CYkk3x1XUvdXCdHtRFdjMjp17PuJ8eR8z

Ответы (1)

Вы вычисляете только адрес P2SH для сценария segwit. Однако это не просто P2SH, это скрипт Segwit, заключенный внутри P2SH. На самом деле вам нужно сначала взять свидетельский скрипт (скрипт с несколькими подписями или segwit redeemScript) и создать с ним выходной скрипт P2WSH. Затем этот сценарий становится сценарием redeemScript для сценария P2SH.

Так дано

5221021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe2103bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38210280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c6553ae

как свидетельский скрипт, вы производите

002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87

как искупительный скрипт. Это сценарий вывода P2WSH. Затем это хэшируется для создания хэша в сценарии P2SH:

a914771962306e72e479245d48e879dd2a1862225b4c87

который имеет адрес

3CYkk3x1XUvdXCdHtRFdjMjp17PuJ8eR8z
Есть ли какой-либо BIP, который определяет это?
Итак, для того, чтобы сгенерировать redeemScript из свидетельского скрипта, нам нужно их созреть?
Нет. Вы должны использовать SHA256 для свидетельского сценария. Затем поместите это в сценарий p2wsh. Затем hash160 этот скрипт для адреса p2sh.
Для нативного Segwit нам это не нужно, верно? Поскольку у нас больше не будет поля sigScript.
Для нативного segwit вам по-прежнему необходимо хешировать свидетельский скрипт. Но нет необходимости делать еще один скрипт и хешировать его. Нативный segwit также имеет другой тип адреса.
Сегвит с мультиподписью
СпросиСетьПолитика конфиденциальности1y, 0v