トランザクション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難しかったけど、ここからスマートコントラクトなどいろいろな応用がきくのか。 ブロックチェーン思った以上に奥が深くて、すごいわ。