272ページ中129〜138ページ。
Mastering Bitcoin 日本語訳 PDF
- Mastering Bitcoin 日本語訳 PDF 全272ページ
前回まで
取引の支払／受取を判別する方法を知りたくてトランザクションの部分から読んでいた。とりあえずその続きから読むことにする。できれば送金に関する部分を把握したいが、気の向くままに読み進める。
標準的なトランザクション
Bitcoinの発展の最初の数年は、開発者たちがBitcoinリファレンスクライアントによって処理されるscriptの 種類にいくつかの制限を加えていました。これらの制限は isStandard() と呼ばれる関数の中にあり、5つの "標準的なトランザクション"の種類が定義されています。これらの制限は一時的なもので、あなたがこれを読 むときまでに解除されているかもしれません。これらの制限が解除されるまでは、5つの標準的なトランザク ションスクリプトだけがBitcoin Coreクライアントやこれを動作させている多くのマイナーに受け入れられています。非標準的なトランザク ションを作ることは可能ですが、このトランザクションをブロックに入れてくれるマイナーを見つけなければ いけません。 どんなscriptが有効なトランザクションscriptとして現在許可されているかを見るためにBitcoin Coreクライアント(リファレンス実装)のソースコードをチェックしてみましょう。 トランザクションscriptの5つの標準的な種類は、pay-to-public-key-hash (P2PKH), public-key, multi- signature (最大15個のキーまで), pay-to-script-hash (P2SH), data output (OP_RETURN)です。これらの詳細な説明は次の節で行います。
pay-to-public-key-hash (P2PKH)public-keymulti-signaturepay-to-script-hash (P2SH)data output (OP_RETURN)
前回、script言語では自由度が高いと話していた。が、実際のところビットコイン業界では上記５つの種類のスクリプトだけ使われているということか。
なんか面倒くさそう。そんなにたくさんの方法が必要なのはセキュリティ関係の理由かな？
Pay-to-Public-Key-Hash (P2PKH)
Bitcoinネットワーク上で処理されているトランザクションの多くはP2PKHトランザクションです。これはBit coinアドレスとして知られている公開鍵ハッシュを伴ったトランザクションアウトプットを拘束しているlock ing scriptを含んでいます。Bitcoinアドレスへの支払いをするトランザクションはP2PKH scriptを含んでおり、このP2PKH scriptでロックされているアウトプットは公開鍵とこの公開鍵に対応したデジタル署名を提示することで解除( 資金の使用)ができます。
たぶんmpurseもこの方式なのだろう。
例えば、AliceがBobのカフェに支払う場面を再度見てみましょう。AliceはこのカフェのBitcoinアドレスに0. 015bitcoinの支払いをします。このトランザクションアウトプットには以下のようなlocking scriptが含まれています。
OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
Cafe Public Key Hash はこのカフェのBitcoinアドレス (Base58Checkエンコーディングが施されていないもの)と同じものです。多くのアプリケーションでは 公開鍵ハッシュ を16進数で表したものを使っており、なじみのある"1"から始まるBase58Check 形式のBitcoinアドレスではありません。
私はbitcoinアドレスなんて持ってないから馴染みもなにもないけどね。とにかく公開鍵ハッシュを16進数で表したものが使われていると。
てことは、自分の公開鍵ハッシュとやらがわかれば、それと一致するかどうかで自分のキーかどうか判断できるのでは？ それをやっているのが上記のscriptなのか？ でも意味がわからないオペレータが多数ある。
| オペレータ | 意味 |
|---|---|
OP_DUP |
？ |
OP_HASH160 |
？ |
OP_EQUAL |
2つのスタックをpopして比較しTRUEかFALSEを返す |
OP_CHECKSIG |
？ |
このlocking scriptは以下のunlocking scriptで条件を満たすことができます。
この2つのscriptを合わせることで、以下の検証scriptの形になります。 OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG これを実行するとき、unlocking scriptがlocking scriptの条件を満たしかつその場合に限り、この結合されたscriptはTRUEと評価されます。他の言い方をする と、もしunlocking scriptがBobのカフェの秘密鍵から作られた有効な署名を持っていれば結果は TRUEになります。 図 と図 は結合されたscriptの逐次実行を(2つの部分で )表しており、この結合されたscriptが有効なトランザクションであることを証明することになります。
vinのscriptSigに秘密鍵から作られた有効な署名とやらが入っていれば、voutにあるscriptPubKeyのscriptはTRUEを返すはず。そのときは有効なトランザクションと判断される。という話か。
で、有効なトランザクション、つまりその支払いに使用されるコインの所有者がちゃんと本人であると確認できたら、その取引を承認し、ブロックチェーンに取り込むべくマイニングを開始する。ということかな？
このスクリプト言語を実行しているのは誰なんだろう。たぶんmpurseで送金するときはmpchain APIを使っているから、mpchainサーバがスクリプト言語を実行しているのだろう。そのプログラムはモナコイン公式サイトにあるフルノードのアプリなのかな？ 数十GBのブロックチェーンをダウンロードできないから自分の環境で確認することもできない。electrum-monaもインストールできなかったし。モヤモヤするなぁ。自分で実際に動作させて確かめたいのに。
Pay-to-Public-Key
pay-to-public-keyはpay-to-public-key-hashよりもよりシンプルなBitcoin支払いの形式です。この script形式は、前に出てきたP2PKHでのとても短い公開鍵ハッシュではなく、公開鍵そのものをlocking scriptに配置しています。pay-to-public-key-hashはBitcoin アドレスをより短くし使いやすくするためにSatoshi Nakamotoによって発明されたものです。現在pay-to- public-keyはcoinbaseトランザクションでよく見られるもので、 P2PKHが使用できるように更新されていない古いマイニングソフトウェアで使われています。 pay-to-public-key locking scriptは以下のようなものです。
古い方法なのね。
<Public Key A> OP_CHECKSIG
アウトプットを解除するために提示されなければならないunlocking scriptは以下のようなシンプルな署名です。
<Signature from Private Key A>
あれ、公開鍵じゃなかったの？ プライベートキーって秘密鍵じゃないの？ そんなわけないか。
トランザクションの有効性検証に使われる結合されたscriptは以下です。
<Signature from Private Key A> <Public Key A> OP_CHECKSIG
このscriptは CHECKSIG オペレーターを使ったシンプルな scriptで、正しい秘密鍵に紐づく署名を検証しています。
「秘密鍵に紐づく署名」とは？ 秘密鍵を引数にしてハッシュ値を出すってことかな？ それが公開鍵ってことなのかな？ それを検証するということは、秘密鍵を知っている必要があるはず。そして秘密鍵は自分のマシンにしか保存されていないはず。それだと自分しか検証できない。ああ、それで十分事足りるのかな？ わからないことが多すぎる。MasteringBitcoin読み飛ばしているせいかもしれない。
オペレータ
ところで、PDFの英語で書いてある図から、さっきわからなかった以下オペレータの意味がわかったっぽい。
| オペレータ | 意味 |
|---|---|
OP_DUP |
スタックのトップにある値と同じものをpushする |
OP_HASH160 |
RIPEMD160(SHA256(PubKey))を実行し、結果をpushする |
OP_EQUAL |
2つのスタックをpopして比較しTRUEかFALSEを返す |
OP_EQUAL_VERYFY |
トランザクションを妨げるPubKeyHashを、ユーザーのPubKから計算されたPubKeyHashと比較します。それらが一致する場合、両方が削除され、実行が続行されます |
OP_CHECKSIG |
CHECKSIG演算子は、署名<sig>がパブリックキー<PubK>と一致することを確認し、trueの場合はTRUEをスタックの最上位にプッシュします。 |
このとき、以下のScriptの意味を考えてみる。
OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHECKSIG
たぶん最初はvinのScriptである公開鍵だか秘密鍵だか何かがスタックに入るのだろう。それと同じものをさらにスタックに入れて、その値をSHA256にかけハッシュ値を算出する。それらを比較して一致するならTRUEを返す。最後に「署名<sig>がパブリックキー<PubK>と一致することを確認し、trueの場合はTRUEをスタックの最上位にプッシュ」する。
だめだ、わからない。そもそも最初のvinをコピーしてSHA256にかけて同じになるわけがなくないか？ 同じ値の片方だけ暗号化したら異なる値になるに決まっていると思うのだが。なにか勘違いしているのかな？
OP_CHECKSIGの説明がある図をみると署名<PubK>はScriptの最初と次のオペレータにみえる。その位置にある値を引数にするという認識であっているのかな？
あと、OP_EQUALで真偽値を返すのが暗号通貨におけるScript言語の役目ではなかったのか？ 最後のオペレータがOP_CHECKSIGであり、それは真偽値をスタックにプッシュするらしい。それはいいけど、直前にあるOP_EQUALの結果は？ 無視されるの？ 何のために実行したの？
どうにも読み取れない。
マルチシグネチャ
マルチシグネチャscriptはN個の公開鍵と、解除条件を解放する少なくともM個の署名が入っている条件を設 定しています。これはM-of-Nスキーマとしても知られており、Nはキーの総数、 Mは検証に必要な署名数です。例えば2-of-3マルチシグネチャでは、あらかじめ登録しておいた署名者の 3つの公開鍵があり、これらのうち2つを使って有効なトランザクションに対する署名を作らなければいけま せん。
複数人の署名がなければ取引が成立しない方法ってことかな？
このとき、標準的なマルチシグネチャscriptは多くても15個の公開鍵だけが使用できるように制限され ており、これは1-of-1から15-of-15までのマルチシグネチャ、またはそれぞれの組み合わせを使用できるということを示しています。この制 限はこの本が出版されるまでに引き上げられるかもしれません。Bitcoinネットワークによって現在何が許可 されているかを見るために isStandard() 関数をチェックしてみてください。
とりあえず上限は15人（アドレス）まで。今は上限解放されているかもしれんと。
M-of-Nマルチシグネチャ条件を設定しているlocking scriptの一般形式は以下です。
M <Public Key 1> <Public Key 2> ... <Public Key N> N OP_CHECKMULTISIG
ただし、Nは登録されている公開鍵の総数、Mはアウトプットを使うにあたって必要な署名数です。
2-of-3マルチシグネチャ条件を設定しているlocking scriptは以下のようなものです。
2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
なるほど。
このlocking scriptは署名と公開鍵のペアを含む以下のunlocking scriptで条件を満たすことができます。
OP_0 <Signature B> <Signature C>
また謎のオペレータが出てきた。OP_0。OP_CHECKMULTISIGもか。
または、登録されている3つの公開鍵に対応する秘密鍵から作られる署名であれば、どんな2つの組み合わせ でも使うことができます。
はあ。
NOTE: 最初に置かれている OP_0 は CHECKMULTISIG のオリジナルの実装にバグがありそれを補完するために必要となっています。このバグとい うのは、 CHECKMULTISIG を実行した時に処理に関係のないスタック上のアイテムを余分に1つpopしてしまうというバ グです。 CHECKMULTISIG 処理は事実 OP_0 を無視して実行され、 OP_0 は単なる空箱のようなものになっています。
バグへの対処だったんかい。
この2つのscriptは以下の結合された検証scriptを形作ります。
OP_0 <Signature B> <Signature C> 2 <Public Key A> <Public Key B> <Public Key C> 3 OP_CHECKMULTISIG
これを実行するとき、unlocking scriptがlocking scriptの条件を満たしかつその場合に限り、この結合されたscriptはTRUEと評価されます。この場合、解除条 件に設定してある3つの公開鍵のうち2つに対応した秘密鍵から作られる有効な署名をunlocking scriptが持っているかどうかが条件になります。
特定の3人中2人からの署名が得られたとき、このトランザクションを有効とみなす。
データアウトプット(OP_RETURN)
Bitcoinの時刻が刻印された分散化元帳であるブロックチェーンは支払い以上のポテンシャルを持っています 。多くの開発者たちは デジタル公証人サービス、株券、スマートコントラクトのようなアプリケーションのためにトランザクションScript言語を使うことでより進んだシステムの安全性や可用性を確保しようとしてきました。当初BitcoinのS cript言語をこれらの目的に使っていく場合、ブロックチェーン上に記録されたデータであるトランザクショ ンアウトプットを利用することが考えられました。これで行う例としては、ファイルの存在証明があります。 これは、このトランザクションが参照している特定の日付を利用して、あるファイルの存在証明(proof-of- existence)を誰でもできるようにします。このことで、ファイルのデジタルフィンガープリントを記録するの です。
ブロックチェーンにはscriptを含めることができる。それを使ってファイル存在証明もできると。それの何が嬉しいの？
bitcoinの支払いと無関係なデータをブロックチェーン上に記録することは物議を引き起こしました。多くの 開発者たちはこのようなブロックチェーンの使い方を汚いものと考え、思いとどまらせようと考えました。ま たある人たちはこれがブロックチェーンテクノロジーの強力な拡張性を示すものと感じ、このような実験を押 し進めようとしました。
何をどう考えるかは人それぞれ。やりたいことも人それぞれ。でもブロックチェーンはひとつ。戦争じゃ！
支払いと関係のないデータを含めることに反対な人たちはこれにより"ブロックチェ ーンの肥大化"を引き起こすと考えており、ブロックチェーンが本来運ぶ必要のなかったデータのためにディ スクストレージのコストが増大しフルノードを動作させているサーバのコストが増えてしまうと考えました。 さらに、このようなトランザクションは使用されないUTXOを作り出し、送り先Bitcoinアドレスの領域20byt eを自由に使える領域として使ってしまいます。このBitcoinアドレスはデータのために使われるので、これは 秘密鍵に対応しておらず 決して使われない UTXOを結果として生み出してしまうのです。これはあたかも偽物の支払いのようになってしまいます。決し て使われないこれらのトランザクションはUTXOセットから決して削除されず、永遠にUTXOデータベースの サイズを大きくし続け、"肥大化"させてしまいます。
取引以外の用途のデータも作れてしまうけど、そうしたらブロックチェーンのデータがムダに肥大化する。マイニングコストや、ブロックチェーン参照など、あらゆる場面でコストが増大してしまうと。
Bitcoin Coreクライアントのバージョン0.9では、妥協策として OP_RETURN オペレーターが導入されました。 OP_RETURN は開発者たちが支払いに関係のない 80byteのデータをトランザクションアウトプットに追加できるようにしています。"偽物の"UTXOと違って、 OP_RETURN オペレーターはUTXOセットに保持される必要がない 明示的使用不可 アウトプットを作り出します。
OP_RETURNは妥協策なのか。というかトランザクションの妥当性チェックとはまるで関係なさそうだな。
OP_RETURN アウトプットはブロックチェーン上に記録されるためディスク容量を消費しブロックチェーンのデータサイズ 増大を促してしまいますが、UTXOセットに保存されないためUTXOメモリプールと高価なRAMのコストの肥 大化にはならないようになっています。
はあ。ディスクは持ってかれるけどメモリからは除外できるのね。
OP_RETURN scriptは以下のようなものです。
OP_RETURN <data>
このdataは80byteに制限され、多くの場合SHA256アルゴリズム(32byte)の出力結果のようなハッシュになっ ています。多くのアプリケーションはアプリケーションを示すidをプレフィックスとしてdataの前に置いてい ます。例えば、 Proof of Existence というデジタル公証人サービスは8byteのプレフィックス "DOCPROOF" を使っていて、ASCIIコードで表すと16進数で 44f4350524f4f46 になります。
ふーん？
OP_RETURN アウトプットを"使用する"ための"unlocking script"がないことを覚えておいてください。つまり、OP_RETURN ではこのアウトプットでロックされている資金を使うことはできないのです。そして、使用可能なものとして UTXOセットに保持しておく必要はありません。このアウトプットに割り当てられているどんなbitcoinも永遠 に失われてしまうため、 OP_RETURN アウトプットは通常0bitcoinを持ちます。もし script検証ソフトウェアが OP_RETURN を見つけた場合には、検証 scriptの実行を直ちに停止しトランザクションを無効にします。このため、もし偶然 OP_RETURN アウトプットをトランザクションインプットが参照した場合は、このトランザクションは無効になります。
OP_RETURNオペレータがあるだけで、取引データではないと判断しちゃうのね。
標準的なトランザクション( isStandard() を確認してみてください)はたった1つだけしか OP_RETURN アウトプットを持つことができませんが、 OP_RETURN アウトプットは他の種類のアウトプットを持つトランザクションと結合することができます。 現在のBitcoin Coreバージョン0.10では2つの新しいコマンドラインオプションが追加されました。 datacarrier オプションは OP_RETURNトランザクションのリレーとマイニングを行うかどうかをコントロールしており、デフォルトは "1"でリレーとマイニングの実行を許可するものになっています。 datacarriersize オプションは数値を引数として取りOP_RETURNデータの最大バイトサイズを指定します。この最大バイトサ イズのデフォルトは40byteです。 OP_RETURNは最初80byteの制限を付けた形で提案されていましたが、この機能が実際にリ リースされた時に制限が40byteに削減されました。2015年2月にリリースされたBitcoin Coreバージョン0.10の中で、この制限は80byteに引き上げられました。ノードはOP_RETUR NOTE Nトランザクションをリレー、マイニングしないか、または単にリレーだけして80byteより 小さいデータを持つOP_RETURNトランザクションだけをマイニングするか、を選べるよう になっています。
面倒くさそうだな。そうまでして暗号通貨システムの中に取引以外のデータを入れたがる理由って何かあるのかな？
モナカードの画像データも取引以外のデータってことなのかな？ そういえばmpurseで送金するときの引数にメモがあって、それも取引データとは違うっぽいし。そのへんのデータはOP_RETURでブロックチェーンに入れているのかな？ それともブロックチェーンとは別のところに保存しているのかな？ やはり知らないことが多すぎる。
Pay-to-Script-Hash (P2SH)
pay-to-script-hash (P2SH)は2012年に導入されたもので、複雑なトランザクション scriptをはるかに簡単化した新しい種類のトランザクションです。P2SHを説明するために、実用的な例を見 てみましょう。
ふーん。
[ch01_intro_what_is_bitcoin]で、ドバイで電子機器の輸入業をやっているMohammedを紹介しました。Mo hammedの会社は会社の口座のためにBitcoinのマルチシグネチャ機能を利用しています。マルチシグネチャs criptはBitcoinの先進的なScript言語の主要な使い方の1つで、とても強力な機能です。Mohammedの会社は 全ての顧客からの支払い(会計用語で"売掛金")にマルチシグネチャを使っています。マルチシグネチャースキ ームを使い、顧客による全ての支払いは次のような方法で安全性を担保しています。支払いを実行するには少 なくとも2つの署名が必要であり、登録されている人はMohammed、彼のパートナーのうちの1人、バックア ップキーを持っている彼の代理人です。このようなマルチシグネチャスキームはコーポレートガバナンスを提 供し、盗難、横領、または紛失を防ぐ役割があります。
先述でみたマルチシグネチャによる有効確認は、やはりセキュリティを向上させるためらしい。一人では使えないって、核ミサイルのスイッチかな？
このためのscriptはとても長く、以下のようなものです。
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
データ量、解析、実行、ともにコスト増大。
マルチシグネチャscriptはとても強力な機能ですが、これは扱いにくいものなのです。というのは、Moham medは支払いをする前にこのscriptについて全ての顧客に説明する必要があるためです。それぞれの顧客は特 別なトランザクションscriptを作ることができる特別なウォレットを使う必要があり、また特別なscriptを使 ってどのようにトランザクションを作ればよいか理解する必要があります。さらに、このscriptがとても長い 公開鍵を含んでいるため、作られたトランザクションは単純な支払いトランザクションと比べて約5倍も大き いのです。そのため、余分に大きいトランザクションデータサイズの負担が顧客ごとのトランザクション手数 料として乗っかってきます。最終的に、このような大きなトランザクションscriptは使用されるまで全てのフ ルノードのRAM内のUTXOセットに保持されます。このような問題点によって実用上、複雑なアウトプットscriptの使用が難しくなってしまうのです。
そんな面倒なことしたら、手軽に使える暗号通貨のよさが半減してしまうものね。ディスられてますよ、マルチさん？
pay-to-script-hash (P2SH) はこれらの実用的な難点を解決するために開発され、 Bitcoinアドレスでの支払いと同じくらい簡単に複雑なscriptを使えるようにしたのです。P2SHでの支払いで 、複雑なlocking script は暗号学的なハッシュであるデジタルフィンガープリントに置き換えられます。
ふーん？
UTXOを使おうとするトラン ザクションがのちに作られたとき、このトランザクションはunlocking scriptだけでなくこのハッシュとマッチするscriptを含んでいなければいけません。簡単に言って、P2SHは" このハッシュとマッチするscriptに対して支払い、このscriptはのちほどこのアウトプットが使用されるとき に与えられます"という意味です。
はあ。
P2SHトランザクションでは、ハッシュによって置き換えられたlocking scriptは redeem script と呼ばれます。なぜなら、これがlocking scriptとしてよりはむしろ回収時にシステムに提供されるからです。P2SHを使用しない複雑なscriptはP2SH ではないscriptを示し、P2SHを使用した複雑なscriptはP2SHでエンコードされた同じscriptを示しています。
わけわからんくなってきた。
Table 4. P2SHを使用しない複雑なscript
| 項目 | 値 |
|---|---|
| Locking Script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG |
| Unlocking Script | Sig1 Sig2 |
Table 5. P2SHを使用した複雑なscript
| 項目 | 値 |
|---|---|
| Redeem Script | 2 PubKey1 PubKey2 PubKey3 PubKey4 PubKey5 5 OP_CHECKMULTISIG |
Locking ScriptOP_HASH160 <20-byte hash of redeem script> OP_EQUAL
Unlocking Script|Sig1 Sig2 redeem script
テーブルにある通りP2SHのほうは、アウトプットを使用するための詳細条件が書かれた複雑なscriptがlocki ng scriptにはありません。その代わり、redeem scriptのハッシュだけがlocking scriptにはあり、redeem script自身はアウトプットが使用されるときのunlocking scriptの一部としてあとで提供されます。
あとで提供ねえ。だれがどうやって提供するの？
Mohammedの会社の場合の複雑なマルチシグネチャscriptとP2SH scriptを見てみましょう。 まず、Mohammedの会社が顧客からの支払いに使っているマルチシグネチャscriptは以下です。
2 <Mohammed's Public Key> <Partner1 Public Key> <Partner2 Public Key> <Partner3 Public Key> <Attorney Public Key> 5 OP_CHECKMULTISIG
上記の大なり小なり括弧を実際の公開鍵(04から始まる520bitの数値)に置き換えてみると、以下のようにとて も長くなってしまうことが分かるはずです。
2 04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984 D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308 EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E632 48B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC1 0F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9 D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1E CED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D1 37AAB59E0B000EB7ED238F4D800 5 OP_CHECKMULTISIG
このscript全体は20byteの暗号学的ハッシュで表現できます。このハッシュは最初にSHA256ハッシュ化アル ゴリズムを適用しその後この結果にRIPEMD160アルゴリズムを適用することで作成されます。前のscriptに 対してのこのハッシュ化して得た20byteのハッシュは以下になります。
54c557e07dde5bb6cb791c7a540e0a4796f5e97e
P2SHトランザクションは、以下のような長いscriptの代わりにこのハッシュを含めたlocking scriptでアウトプットをロックしています。
OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL
見て分かるように前のlocking scriptよりもずいぶん短いことが分かります。"5 つのキーのマルチシグネチャscriptに対する支払い"ではなく、P2SHでは"このハッシュを持ったscriptへの支 払い(pay to a script with this hash)"になります。Mohammed の会社への支払いをする顧客は、とても短いlocking script を含めるだけで支払いができるのです。MohammedがこのUTXOを使いたいときは、オリジナルのredeem scriptと解除するための署名を以下のように提供しなければいけません。
<Sig1> <Sig2> <2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG>
それって結局すごい量になるんじゃないの？ それともOP_CHECKMULTISIGで計算した結果だけ入れるから小さくできるってことかな？
2つのscriptは2つの段階で結合されます。まず、このハッシュが合っているかを確認するためにlocking scriptに対してredeem scriptがチェックされます。
<2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG> OP_HASH160 <redeem scriptHash> OP_EQUAL
もしredeem scriptハッシュが合っていれば、unlocking scriptはredeem scriptを解除するために実行されます。
<Sig1> <Sig2> 2 PK1 PK2 PK3 PK4 PK5 5 OP_CHECKMULTISIG
その後もPay-to-Script-Hash (P2SH)について詳細な説明があったが、ここはそこまで詳しく知らなくてもいいと思って読み飛ばす。
とにかくコインの所有者であることを判定する標準的なScriptの紹介って話だったのだろう。ついていけなかったけど。