トランザクションscript
ビットコインは、locking scriptとunlocking scriptで有効性をチェックする。
locking scriptはアウトプットに置かれている解除条件で将来アウトプットを使用する際に満たさなければいけない条件
scriptは、ほぼほぼハッシュ値だが、逆ポーランド記法で書かれた計算が真ならなんでもよい
例: locking script 3 OP_ADD 5 OP_EQUAL unlocking script 2 2 3 OP_ADD 5 OP_EQUAL となるので真
標準的なscriptは、次の5つ
- P2PKH
- Pay-to-Public-Key
- マルチシグネチャ
- P2SH
- データアウトプットOP_RETURN
P2PKH
locking script OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHCKING unlocking script <Cafe Signature> <Cafe Public Key>
つなげると
<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 <Cafe Public Key Hash> OP_EQUAL OP_CHCKSIG
となって真になる。なるほど。
Pay-to-Public-Key
locking script <Public Key A> OP_CHCKSIG unlocking script <Signature from Private Key A>
つなげると
<Signature from Private Key A> <Public Key A> OP_CHCKSIG
マルチシグネチャ
locking script M <Public Key 1> <Public Key 2>.... <Public Key N> N OP_CHCKMULTISIG unlocking script OP_0 <Signature B> <Signature C>
データアウトプット(OP_RETURN)
scriptにファイルの署名をおけばファイルの存在証明が可能。 そのようにこのscriptを使ってスマートコントラクトなど応用が可能ということが分かってきた。 ただ、ブロックチェーンのデータの肥大化を招くので、ビットコインでは格納できるデータは、80バイトに制限されている。
OP_RETURN
なるほど、なるほど。ここでスマートコントラクトとかの話が出てきて来るのね。
検証側は、OP_RETURNがでてきたら通貨の処理じゃないととらえて処理をやめるのか。
P2SH
マルチシグネチャなど複雑で大きいscriptを実用的にしようとしたもの。 P2SHは、「このハッシュとマッチするscriptに対して支払い、このscriptはのちほどこのアウトプットが使用するときに与えられる。」なんとなくは分かった(笑) locking scriptにscriptのハッシュを置くのね。
redeem Script マルチシグネチャなどのscript locking script OP_HASH160 <マルチシグネチャなどのscriptの20バイトのハッシュ値> OP_EQUAL unlocking script SIg1 Sig2 redeem script
結果、手数料と複雑性の負担がトランザクションの送り手から受け手に移られるのか。
pay to a script hashの名前のとおり、このハッシュを持ったscriptへのハッシュということか。
P2SHアドレス
scriptのハッシュをアドレスとして使用する。 支払ってくれる人にこのアドレスを伝えればよい。 支払う人がscriptを見ることなく支払いができるようにできる。
script難しかったけど、ここからスマートコントラクトなどいろいろな応用がきくのか。 ブロックチェーン思った以上に奥が深くて、すごいわ。