Bitcoin スクリプトから理解するライトニングネットワーク

Bitcoin スクリプトから
理解する
ライトニングネットワーク
そしてこの文脈で何故 segwit が重要か
発表者: Yuki INOUE

About Me
● Yuki INOUE
○ Twitter とかあんまやってません、、すいません。。
● カウンティア株式会社所属
○ ウォレットの研究開発とかやっています。
● スタックオーバーフロー日本語版のモデレータとか。
○ コミュニティドリブンな、プログラミングの QA サイト!

目的
● 背景: ライトニングネットワークについて、一通して理解できるような資料が見つから
ない。
● なのでこれを、いわば mastering lightning network 的な理解ができたらいいな、と
思った。
● 目標は、ライトニングの技術的な設計について理解できるようになること。

目次
1. Bitcoin のアドレス(スクリプト)についての説明
2. ライトニングの動作説明
3. ライトニングネットワークにおいて必要という文脈での segwit

1. Bitcoin スクリプトについて
そのためにまず bitcoin の確認

確認: bitcoin とは
● アドレスからアドレスにコインを送る Transaction がある
● Transaction が P2P で共有される
○ Transaction を P2P に流すこと == Transaction を Broadcast する
● Transaction を束にして block に固める、 mining というオペレーションがある。
○ block も P2P で共有されていく
● Lightening network ではこの Transaction に注目する。
では Transaction の中身とは

Transaction == TxInput の配列 + TxOutput の配列

TxIn と TxOut の役割
● TxIn は送り元アドレス + 今作っている Tx の署名に大体、相当
● TxOut は送り先アドレス + 送金する量に相当
● そしてアドレス ≒ 公開鍵

アドレス、署名、Transaction
Alice
Bob Charlie
APub -> BPub: 10BTC
Signed By APriv.
Tx0
BPub -> CPub:
10BTC
Signed by BPriv.
Tx1

ところで
● アドレスからアドレスにコインを送る Transaction がある。
は正しくない。
● 「過去の Transaction の出力」からアドレスにコインを送るのが Transaction
● 既に送金された「過去の Transaction の出力」から再度送金しようとする Tx は不
正として bitcoin protocol から弾かれる。

ところで: 正確にはアドレス -> アドレスではない
APub -> BPub: 10BTC
Signed By APriv.
Input:
* (TxZ, 0) Signed By APriv.
Output:
* 10BTC on BPub
Input:
* (TxA, 0) Signed By BPriv.
Output:
* 10BTC on CPub
TxA
Unspent Transaction Output
(UTXO)
TxB

(考察) 何故 UTXO か。
● アドレスないし「アドレス残高」からの出金だと不都合がある。
● 例: 入金・出金を繰り返した。
○ 入金 -> 入金 -> 出金 -> 出金(残高不足でこれは失敗する ) がやりたかった。
○ 出金 -> 出金 -> 入金 -> 入金の順で到着した場合 ?
● 例: Transaction に手数料が足りずに mining されなかったので、手数料を増やし
て作り直して再送したい。
○ 受け取り側が悪意のある miner で、新しい方を confirm したのちに、古いほうをまた confirm してし
まったら?

再定義: TxIn と TxOut
● TxIn : 過去の TxOut の場所と、それに対応する署名
● TxOut: 送り先アドレスと数量

Bitcoin Transaction: scriptSig, scriptPubKey: 署名と
公開鍵の仕組みの汎用化。
● 語弊を恐れずに言えば: 「署名」と「公開鍵」の部分に好き勝手なスクリプトを入れて
いいよ。
● どう行われる: 「公開鍵」を「解除条件」、「署名」を解除のためのデータ。
● それぞれ同一のスクリプトで記述して、つなげた時に、スクリプトが正常終了するこ
と。
具体例から入ります

具体例: (旧) アドレス方式: P2PK
● TxOut: scriptPubKey: “pubkey(定数)” OP_CHECKSIG
● TxIn: scriptSig: “sig(定数)”
● 「定数」とは、それをスタックに載っけてくれ、という指示詞
スタックスクリプト次の action
(空) <sig> <pubkey> OP_CHECKSIG <sig> を push
<sig> <pubkey> OP_CHECKSIG <pubkey> を push
<sig> <pubkey> OP_CHECKSIG スタックの top を公開鍵、 top-1 を
署名としてこの Tx を検証
true スクリプト終了時の top の値が非
0 ならば、 accept.

具体例: 現行のアドレス方式: P2PKH
● scriptPubKey: OP_DUP OP_HASHSHA256 “pubkeyhash(定数)”
OP_EQUALVERIFY OP_CHECKSIG
● scriptSig: “sig(定数)” “pubkey(定数)”
スタックスクリプト Action 特記
(空) <sig> <pubkey> OP_DUP OP_SHA256
<pubkeyhash> OP_EQV OP_CHECKSIG
Sig, pubkey を push。 Stack top
の pubkey が dup されて sha256
される。
<sig> <pubkey>
<pubkeyhash>
<pubkeyhash> OP_EQV OP_CHECKSIG Pubkeyhash が push され == 比
較される
<sig> <pubkey> OP_CHECKSIG 以降P2PK と同じ流れになる。
詳細は例えば: https://en.bitcoin.it/wiki/Script

スクリプト言語でできること
● スタック2つ (main, push/pop のみできる alt)
● 分岐処理
● もろもろの暗号演算
● 基本的四則演算、 push/pop/drop などの簡単な stack 操作
● できないこと: loop 処理。
● イメージ、 Excel の関数と同じぐらいのことができる。

具体例: 2 of 2 マルチシグアドレスっぽいもの自作
# scriptSig 部分
sigA
sigB
# scriptPubKey 部分
pubB
OP_CHECKSIG
OP_NOTIF
OP_RETURN
OP_ENDIF
pubA
OP_CHECKSIG
スタックスクリプト
(空) <sigA> <sigB> <pubB> OP_CHECKSIG OP_NOTIF
OP_RETURN OP_ENDIF <pubA> OP_CHECKSIG
<sigA> <sigB> <pubB> OP_CHECKSIG OP_NOTIF OP_RETURN
OP_ENDIF <pubA> OP_CHECKSIG
<sigA> true OP_NOTIF OP_RETURN OP_ENDIF <pubA>
OP_CHECKSIG
<sigA> <pubA> OP_CHECKSIG
TxIn
TxOut
POINT: if 文が使える。

OP_CHECKLOCKTIMEVERIFY + p2pkh
● scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY
OP_CHECKSIG
● scriptSig: <sig> <pubkey>

スクリプトポイント
● ループを含まない、CHECKSIG や暗号ハッシュを組み合わせた任意の条件を記
述できる。
● 特定の時刻ないしブロック高まで unlock できないアドレスを作れる

Lightning Network 概要
● Block を経由しないで Tx をやりとりしていこうとするオフチェーン技術
● 基本は、A さんと B さんの双方向 payment channel.
● 双方向 payment channel をつなげてネットワークにしたもの。

注目点1: 誰が broadcast できるかゲーム木
UTXO0
Tx1a
Out: Bob
Alice can BroadCast
Bob can BroadCast
On Block Not On Block (Yet)
Out: Special1
Tx1b
Out: Alice
Out: Special2
Tx2a Out: Bob
Bob can BroadCast

注目点2: 署名検証のロジック (OP_CHECKSIG)
Transaction
TxIn1
TxOut1 TxOut2
Txid
index
Script
Sig1
TxIn2
Txid
index
Script
Sig2
TxIn1
TxOut1 TxOut2
Txid
index
Script
PK1
TxIn2
Txid
index
Script
Sig1
Script
PK1
CHECKSIG

注目点2: TxIn は個別に署名していくことができる。
Tx: OnBlock
TxIn:sig0 Out(5):
Alice
TxIn:sig1
Tx: WIP
TxIn:
AliceSig
Out(10):
KevinTxIn:
_______Tx: OnBlock
TxIn:sigA Out(5):
Bob
TxIn:sigB

双方向 payment channel 概要
● チェーンに書き込むことなく、書き込まれない想定の Tx のみをやりとりして支払い
を実現する。
● お互いに multisig アドレスに deposit (channel を開くのはブロックチェーン上に書
き込む必要がある)
● 払い戻しの Tx をお互いに保持しておく。
● Alice と Bob に支払ったら、チェーンに書きこむのではなく、払い戻し Tx を更新す
る。
● 払い戻し Tx を更新する際に、古い Tx を無効化するような Tx も発行しておく。

チャンネルが満たすべき性質
● お互いが、今持っているべきコインを、相手が何をしようとも(最終的には)受け取れ
る
● ゲーム木的に、相手が一方的に得するようなことがないようにする
● 支払いで Tx 更新を行う際には、支払い前か支払い後のどちらか一方のみが有効
になるようにする

実現手段
● Timelock 付きの脱出経路を A, B どちらも常に実行できるようにする。
○ Abort できる。
● 破棄したい Tx は、一時秘密鍵を相手に渡すことでゲーム理論的に自分・相手がそ
れを実行しなくなる。

事前準備: それぞれ一時的なアドレスを生成する。
● 普通の、アドレスにひもづく秘密鍵 <-> 公開鍵のペアを、生成する。
● それら一時的アドレスは、相手に共有しておく。
● Alice: AliceTmp1, AliceTmp2, …
● Bob: BobTmp1, BobTmp2, …

まず: チャンネルをオープンする

はじめに: Alice が Deposit Tx 用意
Tx0: not broadcasted
TxIn: __ Out(10):
AlicePub
and
BobPubTxIn: __
Nobody can Broadcast
TxOut(5):
AlicePub
TxOut(5):
BobPub

Tx1Bob: {5, 5}
TxIn: AliceSig,
missing BobSig
Out(5): AlicePub
Out(5):
{Timelock to BobPub}
Or
{AlicePub and
BobTmp1Pub}
Alice が Bob が実行できる払い戻し Tx 用意・共有
TxIn: Alice(5) + __ Out(10):
AlicePub
and
BobPubTxIn: Bob(5) + __
Nobody can Broadcast Bob can Broadcast

Tx1Alice: {5, 5}
TxIn: BobSig,
missing AliceSig
Out(5): BobPub
Out(5):
{Timelock to AlicePub}
or {BobPub and
AliceTmpPub}
Bob が、 Alice が実行できる払い戻し Tx 用意・共有
TxIn: Alice(5) + __ Out(10):
AlicePub
and
Nobody can Broadcast
Bob can Broadcast
Tx1Bob: {5, 5}
Alice can Broadcast

Alice が Deposix Tx に署名
TxIn: Alice(5) + sig Out(10):
AlicePub
and
Bob can Broadcast
Bob can Broadcast
Tx1Bob: {5, 5}
Alice can Broadcast
Tx1Alice: {5, 5}

Tx1Bob: {5, 5}
TxIn: AliceSig,
missing BobSig
Out(5): AlicePub
Out(5):
{Timelock to BobPub} or
{AlicePub and
BobTmp1Pub}
Alice が Deposix Tx に署名・共有: Tx1Bob 系
AlicePub
and
Bob can Broadcast
Bob can Broadcast
Tx1Alice: {5, 5}
Alice can Broadcast
Alice 収益:
5 BTC

Tx1Bob: {5, 5}
TxIn: AliceSig,
missing BobSig
Out(5): BobPub
Out(5):
or {BobPub and
AliceTmp1Pub}
Alice が Deposix Tx に署名・共有: Tx1Alice 系
Alice
and
BobTxIn: Bob(5) + __
Bob can Broadcast
Bob can Broadcast
Tx1Alice: {5, 5}
Alice can Broadcast
Alice 収益:
1000 時間後
5 BTC

Bob が Opening Tx を Broadcast
Tx0: broadcasted
AlicePub
and
BobPubTxIn: Bob(5) + sig
Bob can Broadcast
Tx1Alice: {5, 5}
Alice can Broadcast
Tx1Bob: {5, 5}

Alice が Bob に 1 BTC 支払う
{5, 5} もしくは、 {4, 6} のみが成立するようにしながら、
最後に {4, 6} のみが有効になるように

Alice が、更新したBob用払い戻し Tx 作成共有
Out(10):
AlicePub
and
BobPub
Bob can Broadcast
Tx1Alice: {5, 5}
Alice can Broadcast
Tx1Bob: {5, 5}
Tx2Bob: {4, 6}
TxIn: AliceSig,
missing BobSig
Out(4): AlicePub
Out(6):
{Timelock to BobPub}
or {AlicePub and
BobTmp2Pub}
Bob can Broadcast

Bob も、更新した Alice 用払い戻し用の Tx 作成共有
Out(10):
AlicePub
and
BobPub
Tx1Alice: {5, 5}
Alice can Broadcast
Bob can Broadcast
Tx1Bob: {5, 5}
Bob can Broadcast
Tx2Bob: {4, 6}
Alice can Broadcast
Tx2Alice: {4, 6}

Alice が、Bob に AliceTmp1 の秘密鍵を渡す
Out(10):
AlicePub
and
BobPub
Alice can Broadcast
Bob can Broadcast
Tx1Bob: {5, 5}
Bob can Broadcast
Tx2Bob: {4, 6}
Alice can Broadcast
Tx2Alice: {4, 6}
Tx1Bob: {5, 5}
TxIn
Out(5): BobPub
Out(5):
or {BobPub and
AliceTmp1Pub}
TxIn: AliceTmp1Sig
And BobSig
Bob can Broadcast
TxIn: AliceSig
Alice can Broadcast
After 1000 hours
Alice の収益:
0 BTC

Bob も、Alice に BobTmp1 の秘密鍵を渡す
Out(10):
AlicePub
and
BobPub
Tx1Alice: {5, 5}
Alice can Broadcast
Bob can Broadcast
Tx1Bob: {5, 5}
Bob can Broadcast
Tx2Bob: {4, 6}
Alice can Broadcast
Tx2Alice: {4, 6}
All to Bob
Bob can Broadcast
All to Alice
Alice can Broadcast
0.5, 0.5
Bob can boardcast
After 1000 hours
0.5, 0.5
Alice can boardcast
After 1000 hours

Close 用 Tx 作ってそれを Broadcast
Out(10):
AlicePub
and
BobPub
Bob can Broadcast
TxNBob: {4, 6}
Alice can Broadcast
TxNAlice: {4, 6}
TxIn: AliceSig,
BobSig
Out(4): AlicePub
Out(6): BobPub

Channel が閉じられた後
Out(10):
AlicePub
and
BobPub
Commit Tx
TxIn: AliceSig,
BobSig
Out(4): AlicePub
Out(6): BobPub

PaymentChannel をネットワーク化する
A
C
B
D
E
F
H
G
I

Lightning Network 具体的に何をやっているか
● Alice が Charlie に送る
● Alice -> Bob -> Charlie
● 方法:
○ Tmp (秘密鍵) があれば完了する送金、 TimeLock で自分自身に遅りながら。
○ Alice -(7 days)-> Bob -> (5 days) -> Charlie で Tx を作って、 Charlie は自分に届いたら Secret
をバラまく。

Lightning Network の概念的な図示
Alice
Bob
Charlie
or
BobSig and
CharlieTmpToken
Timelock to AliceSig
CharlieSig and
CharlieTmpToken
Timelock to
BobSig
or

Timelock on Payment Channel
TxNBob: {5, 5}
TxIn: AliceSig,
missing BobSig
Out(5): AlicePub
Out(5):
{Timelock to
BobPub} or
{AlicePub and
BobTmpPub}
TxnBob: {4, 5, 1}
TxIn: AliceSig,
missing BobSig
Out(4): AlicePub
Out(5):
{Timelock to
BobPub} or
{AlicePub and
BobTmpNPub}
Out(1):
{Timelock to
AlicePub} or
{BobPub and
CharlieTmpToken}

L.N. は TxOut が変わらないことを前提にしている
● TxIn は TxOut を (Txid, n) で参照する。
● TxId は、segwit を考えない場合は、以下で計算される
sha256^2( Tx という TxIn と TxOut の集合的データ )
-> TxIn の署名部分が変わるたびに TxId も変わる。

なので: 署名部分(scriptsig) を別領域へ
Inputs Outputs
Sig
Sig
TxId
Inputs Outputs
Sig
Sig
TxId
WitnessTxId Witness Merkle Tree へ

まとめ
● Bitcoin の Tx の、特に script まわりを見てきた
● Lightning Network が、 UTXO のロック的側面を利用して、ゲーム木的に支払いを
実装していることを説明した
● Lightning Network には segwit が必須であることを見た。

ご静聴ありがとうございました!

Bitcoin スクリプトから理解するライトニングネットワーク

More Related Content

Similar to Bitcoin スクリプトから理解するライトニングネットワーク

Bitcoin スクリプトから理解するライトニングネットワーク