ビットコインのゴックス事件で話題になりました「弱いところ」について、解説します。

1. Transaction
Malleabilityについて
作：アンダーウッド・ジョナサン

2. 概要
①背景・簡単な説明
②取引ＩＤについて
③署名と取引の関係
④スクリプトの実行時
⑤展性について(代表例)
ア）scriptSigの余分なOP
イ）scriptSigのPUSHDATA系OPの変更
ウ）ECDSA署名のs値のネガティブ
エ）Sighashで署名の含まれる範囲を指定
オ）秘密鍵持つ人自身が再度署名をする。
⑥BIP62で解決？
⑦展性から影響を受けないようにするには？
⑧結論

3. 背景・簡単な説明
・2011年中旬に発覚
・署名のDER必須化な
ど一部対策は打った
・避けられないものと判
断し、「これ以上の対策
はしない」と断言
・2014年、MtGox事件
・取引の情報を変更せ
ずに取引ＩＤが変更可能
・秘密鍵不要
・ノードから見たら
ダブルスペンドと同じ
扱い

4. 取引ＩＤについて
・含まれるもの： 01000000 //バージョン
01 // 入力の数
227b59624bfc0acb51bde9b02a19ac98b62625ead0dd2093596b56e45d94a638 // 入力参照取引
00000000 // 参照出力索引
6a47304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622
02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601 //署名
2102d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66 // 公開鍵
ffffffff // Sequence
02 // 出力の数
c0372a0100000000 // 出力の額
1976a914c9868552872337050efec29054cbfccea104de0a88ac // scriptPubkey
ca5f5e0000000000 // 出力の額
1976a914bfc64676ab297c0a6b8b738b8d6689caaf82658188ac // scriptPubkey
00000000 // nLockTime
scriptSig
全部
取引ＩＤは右記に対し
sha256(sha256(tx))
⇒リトルエンディアン

5. 署名と取引の関係
・署名に含まれるもの：
(SIGHASH_ALLの場合)
01000000
01
227b59624bfc0acb51bde9b02a19ac98b62625ead0dd2093596b56e45d94a638
00000000
6a47304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c162
202206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601
2102d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66
ffffffff
02
c0372a0100000000
1976a914c9868552872337050efec29054cbfccea104de0a88ac
ca5f5e0000000000
1976a914bfc64676ab297c0a6b8b738b8d6689caaf82658188ac
00000000
含まれない
scriptSigの代わりに
参照先出力のscript
Pubkey
(P2SHの場合、
redeemscript)を挿入
し、取引の
最後に4バイトの
sighash_typeを付け
る。

6. スクリプトの実行時1
・入力が参照している出力のscriptPubkey
と当該入力に含まれるscriptSigを実行。
(scriptSig⇒scriptPubkey)
先ほどの例で実行してみましょう
scriptSig:
①OP_PUSHDATA
304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622
02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601
②OP_PUSHDATA 02d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66
scriptPubkey:
③OP_DUP ④OP_HASH160 ⑤OP_PUSHDATA f8a60ea80148db1dd98a463151d315eb816d1035 ⑥OP_EQUALVERIFY ⑦OP_CHECKSIG
スタックを見ると。。。⇒

7. スクリプトの実行時2

8. 展性について(代表例)
ア）scriptSigの余分なOP
署名済みのscriptSigは署名に含まれないで取引ＩＤに含まれ
るので、余分なOP_CODE入れれば取引ＩＤが変わる。
例の取引で言うと：
scriptSig:
＋OP_0 ＜＜＜OP_0を先頭に挿入。Scriptの実行には影響なし。署名はまだ有効。取引ＩＤが変わる。
①OP_PUSHDATA
304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622
02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601
②OP_PUSHDATA 02d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66
scriptPubkey:
③OP_DUP ④OP_HASH160 ⑤OP_PUSHDATA f8a60ea80148db1dd98a463151d315eb816d1035 ⑥OP_EQUALVERIFY ⑦OP_CHECKSIG

9. 展性について(代表例)
イ）scriptSigのPUSHDATA系OPの変更
PUSHDATAに種類が複数あり、(数字が大きくなれば変わる)
しかし小さい数字に対して大きい数字用のPUSHDATA使っても有効
例の取引で言うと：
scriptSig:
①OP_PUSHDATA4
304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622
02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601
②OP_PUSHDATA2 02d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66
scriptPubkey:
③OP_DUP ④OP_HASH160 ⑤OP_PUSHDATA f8a60ea80148db1dd98a463151d315eb816d1035 ⑥OP_EQUALVERIFY ⑦OP_CHECKSIG

10. 展性について(代表例)
ウ）ECDSA署名のs値のネガティブ
署名のs値の+-を逆にしても計算上有効であるため、orderから
sの値を引いて置き換えると異なるデータとなって、まだ有効。
例の取引で言うと：
scriptSig:
①OP_PUSHDATA
304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622
0221009229be2186f747cd436f827b60f76fe10a8096af3ff7cff3a79694dae8deb68b01
②OP_PUSHDATA 02d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66
scriptPubkey:
③OP_DUP ④OP_HASH160 ⑤OP_PUSHDATA f8a60ea80148db1dd98a463151d315eb816d1035 ⑥OP_EQUALVERIFY ⑦OP_CHECKSIG

11. 展性について(代表例)
エ）Sighashで署名の含まれる範囲を指定
一般的に使われるSIGHASH_ALLに対して、出力の中身を全
く署名に含めないSIGHASH_NONEを利用すると、いくらでも出
力の内容を変更できるので取引ＩＤが変わるのは仕方無い。
その他のSIGHASHタイプ：
SIGHASH_ALL：出力全て、そして入力の参照先全てを含める。
SIGHASH_NONE：入力の参照先を全て含め、出力は全く含めない。
SIGHASH_SINGLE：入力の参照先を全て含め、でも他入力のSequenceは含めずに、1つの出力のみ含める。
(＊SIGHASH_ANYONECANPAY：上記3つのどれにも併用でき、これを併用すると他の入力の参照先を含めない。)

12. 展性について(代表例)
オ）秘密鍵持つ人自身が再度署名をする。
署名で異なる乱数を使い、再度署名して配信すると取引ＩＤが
異なる。
…当たり前か…

13. BIP62で解決？
・既述の問題を含め、他の展性の原因を抑止する
ためにスタンダードルールを変更しようとしている
・しかし、(エ)と(オ)はビットコインの根本的な仕様と
関わっており、変更が不可能。
・トランザクション展性は抑えることできても
修正不可

14. 展性から影響を受けないようにするには？
・ＤＢで出金依頼とutxo情報を結び付ける。
－Mt.Goxは取引ＩＤのみで管理
・出金後しばらくは出金元のアドレスに関する取引を
監視する。

15. 結論
・トランザクション展性は仕方が無いこと
・取引ＩＤのみを頼りにすると詐欺に遭う可能性あり
・utxoの行方を追うことが大切

16. 質疑応答に入りたいと思います。
御清聴ありがとうございました。