Оплата за выполнение хэша скрипта

Комбинируя скрипт транзакции расходования Sig и скрипт транзакции финансирования PubKey, мы получаем:

<OP_0> <sig A> <sig C> <redeemScript> <OP_HASH160> <redeemScriptHash> <OP_EQUAL>

Пошаговое выполнение этого скрипта:

1)OP_0 и две подписи добавляются в стек, оставленные на потом.

2) RedeemScript добавляется в стек.

3) OP_HASH160 хэширует наш redeemScript.

4) redeemScriptHash добавляется в стек.

5) OP_EQUAL сравнит OP_HASH160(redeemScript) и redeemScriptHash и проверит их на равенство. Это подтверждает, что наша расходная транзакция предоставляет правильный сценарий погашения.

6) Теперь можно оценить наш redeemScript:

<OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> <OP_CHECKMULTISIG>

7) OP_CHECKMULTISIG просмотрит 3 открытых ключа и 2 подписи в стеке и сравнит их одну за другой. Как указывалось ранее, порядок подписей здесь имеет значение и должен соответствовать порядку, в котором были предоставлены открытые ключи.

8) OP_0 включен только для устранения ошибки «не на единицу» в Bitcoin Core при использовании OP_CHECKMULTISIG.

я прочитал несколько ответов, связанных с этой темой, и я также прочитал BIP16, но я до сих пор не могу понять, как после проверки с помощью <OP_EQUAL>вычисляется <redeemScript>с помощью , <OP_HASH160>и <redeemScriptHash>сценарий продолжается с проверкой<sig A> <sig C>

После процедуры, которую я уже описал, в стеке остаются только следующие части: <OP_0> <sig A> <sig C>Как эти подписи будут проверены после того, <redeemScript>как они будут извлечены из стека?

Другими словами, мой вопрос связан с шагом 6. Теперь можно оценить наш redeemScript: как он был удален из стека...