Transactions

P2SH 非隔離見證和沒有多重簽名

  • March 11, 2020

我有一個 P2SH 沒有隔離見證地址 (regtest) 我使用我的公鑰創建兌換腳本SHA256RIPEMD160預先添加0x0014

---------- Redeem Script --------- 
001407b01acbc2869d92912d50de6c7a6b9cb31487f0

---------- scriptPubKey --------- 
36e74f3c86af031ee34a4552c0d935d180db0a26

---------- ADDRESS P2SH️ --------- 
2MxFXaJvTozTJNZmd6E53wwFX7RnbDkGsGe

之後我想手動創建一個事務。我將redeem_script 放入scriptSig 佔位符並簽署交易數據。

之後,我使用我的簽名創建交易,甚至在 scriptSig 中添加redeem_script(如P2SH multi sig)

我的最終交易數據是:

0200000001f1838b3d294b74a1869140f538ba895b7aef81eab5e87206725ef1f868598a01000000005F47304402204a181d59fd36fb921d68596a4ae89ee6aef6980ab4a2f433ff28be4760744b76022027752d2a405c20aeda51038a8dccc3f2c0df1088fdebaee5f1eed9fad6ae086b0116001407b01acbc2869d92912d50de6c7a6b9cb31487f0ffffffff016036f829010000001976a9143dc3d9dc346b539125506ca681442d89c336813688ac00000000

I get this error:
mandatory-script-verify-flag-failed (Opcode missing or not understood) (code 16)

我想了解 P2SH(無多重簽名)的工作原理

要理解這一點,您首先必須意識到,儘管比特幣 wiki說比特幣腳本評估並不像執行類似 Forth 的語言那麼簡單。更準確地說不是1) read 2) run。相反,它更像1) read 2) interpret (decide how to run) 3) construct the entire script based on 2 4) run. 而且它不僅僅是“從左到右”的評價。相反,它總是從最右邊開始(上一個交易,即正在PubkeyScript花費的 tx)然後從左邊繼續(現在可能不同)。

專注於 P2SH,這裡有一些例子(假設讀者知道每個 OP 程式碼的作用,否則先看看上面的 wiki 連結):

  1. 首先獲取PubkeyScript正在花費的交易並對其進行評估以決定如何繼續。這裡我們只關注具有這種模式的 P2SH OP_HASH160 <20 bytes push> OP_EQUAL:. 因為它是 P2SH,所以我們繼續這樣:
  2. 僅從該腳本開始SignatureScript並“執行”。最後必須包含至少一個PushData操作(腳本只能是 1 次推送,也可以是其他以 1 次強制推送結尾的 OP)
  3. 複製強制推送
  4. 如果它們相等,則PubkeyScript使用該重複項 ( )執行,否則將失敗。pop1>hash>pushResult>push20>pop2>equalityCheck
  5. 將強制推送評估為腳本(即。RedeemScript)並決定如何繼續。
  6. 以下是不同的情況:

6.1。RedeemScript = OP_0 <20 bytes push>

6.2. RedeemScript = OP_0 <32 bytes push>

6.3. RedeemScript = whatever else(我認為除了以上2種之外沒有其他特別的模式了)

案例 6.3 可能是最簡單的,因為它只是“執行” RedeemScript. 我說“其他”,因為只要不是“特殊模式”,評估就非常簡單和“正常”。您可以在區塊鏈上輕鬆找到的所有遺留多重簽名 P2SH 交易中看到這一點。但這裡有另一個例子,用一個非常簡單的 RedeemScript 來顯示“其他”的含義:463782617f0e6a69102530caa9ba2fe48f996128378af99ee437a22660afc5a7用作OP_2 OP_3 OP_ADD OP_5 OP_EQUALRedeemScript僅 1 次強制推送)。

案例 6.1 和 6.2 更難,也有點棘手,因為在評估期間,您必須“執行”腳本中甚至不存在的 OP 程式碼!例如,在 6.1 或P2SH-P2WPKH的情況下,您可以這樣繼續:

  1. 確保沒有超過單一PushDataSignatureScript.
  2. 查看證人並期待 2 個項目,提取那些
  3. 為 SegWit 交易執行一個特殊的OP_CheckSig(雖然它不存在)。這意味著:第 8 步中的第一項是簽名,第二項是公鑰。sigHash按照 BIP-143 中的說明計算,執行ECDSA.Verify(signature,sigHash,pubkey).

對於 6.2,事情變得更加複雜,因為現在有一個WitnessScript應該單獨評估的(有點類似於RedeemScript)。

引用自:https://bitcoin.stackexchange.com/questions/93709