Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ビットコイン ~ トランザクション展性について

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

  • Login to see the comments

ビットコイン ~ トランザクション展性について

  1. 1. Transaction Malleabilityについて 作:アンダーウッド・ジョナサン
  2. 2. 概要 ①背景・簡単な説明 ②取引IDについて ③署名と取引の関係 ④スクリプトの実行時 ⑤展性について(代表例)   ア)scriptSigの余分なOP   イ)scriptSigのPUSHDATA系OPの変更   ウ)ECDSA署名のs値のネガティブ   エ)Sighashで署名の含まれる範囲を指定   オ)秘密鍵持つ人自身が再度署名をする。 ⑥BIP62で解決? ⑦展性から影響を受けないようにするには? ⑧結論
  3. 3. 背景・簡単な説明 ・2011年中旬に発覚 ・署名のDER必須化な ど一部対策は打った ・避けられないものと判 断し、「これ以上の対策 はしない」と断言 ・2014年、MtGox事件 ・取引の情報を変更せ ずに取引IDが変更可能 ・秘密鍵不要 ・ノードから見たら ダブルスペンドと同じ 扱い
  4. 4. 取引IDについて ・含まれるもの: 01000000 //バージョン 01 // 入力の数 227b59624bfc0acb51bde9b02a19ac98b62625ead0dd2093596b56e45d94a638 // 入力参照取引 00000000 // 参照出力索引 6a47304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622 02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601 //署名 2102d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66 // 公開鍵 ffffffff // Sequence 02 // 出力の数 c0372a0100000000 // 出力の額 1976a914c9868552872337050efec29054cbfccea104de0a88ac // scriptPubkey ca5f5e0000000000 // 出力の額 1976a914bfc64676ab297c0a6b8b738b8d6689caaf82658188ac // scriptPubkey 00000000 // nLockTime scriptSig 全部 取引IDは右記に対し sha256(sha256(tx)) ⇒リトルエンディアン
  5. 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. 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. 7. スクリプトの実行時2
  8. 8. 展性について(代表例) ア)scriptSigの余分なOP  署名済みのscriptSigは署名に含まれないで取引IDに含まれ るので、余分なOP_CODE入れれば取引IDが変わる。 例の取引で言うと: scriptSig: +OP_0  <<<OP_0を先頭に挿入。Scriptの実行には影響なし。署名はまだ有効。取引IDが変わる。 ①OP_PUSHDATA 304402201e815830e3cdc6854643a96d0784863263a6c81907e3e156b8177bb0e58c1622 02206dd641de7908b832bc907d849f08901db02e46376f50d048183bc9b1e7578ab601 ②OP_PUSHDATA 02d7697f67f07afc87e7bb19bdcd08607c7f87fbe934bb83a0af2245fc2725fe66 scriptPubkey: ③OP_DUP ④OP_HASH160 ⑤OP_PUSHDATA f8a60ea80148db1dd98a463151d315eb816d1035 ⑥OP_EQUALVERIFY ⑦OP_CHECKSIG
  9. 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. 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. 11. 展性について(代表例) エ)Sighashで署名の含まれる範囲を指定  一般的に使われるSIGHASH_ALLに対して、出力の中身を全 く署名に含めないSIGHASH_NONEを利用すると、いくらでも出 力の内容を変更できるので取引IDが変わるのは仕方無い。 その他のSIGHASHタイプ: SIGHASH_ALL:出力全て、そして入力の参照先全てを含める。 SIGHASH_NONE:入力の参照先を全て含め、出力は全く含めない。 SIGHASH_SINGLE:入力の参照先を全て含め、でも他入力のSequenceは含めずに、1つの出力のみ含める。 (*SIGHASH_ANYONECANPAY:上記3つのどれにも併用でき、これを併用すると他の入力の参照先を含めない。)
  12. 12. 展性について(代表例) オ)秘密鍵持つ人自身が再度署名をする。  署名で異なる乱数を使い、再度署名して配信すると取引IDが 異なる。 …当たり前か…
  13. 13. BIP62で解決? ・既述の問題を含め、他の展性の原因を抑止する ためにスタンダードルールを変更しようとしている ・しかし、(エ)と(オ)はビットコインの根本的な仕様と 関わっており、変更が不可能。 ・トランザクション展性は抑えることできても 修正不可
  14. 14. 展性から影響を受けないようにするには? ・DBで出金依頼とutxo情報を結び付ける。   -Mt.Goxは取引IDのみで管理 ・出金後しばらくは出金元のアドレスに関する取引を 監視する。
  15. 15. 結論 ・トランザクション展性は仕方が無いこと ・取引IDのみを頼りにすると詐欺に遭う可能性あり ・utxoの行方を追うことが大切
  16. 16. 質疑応答に入りたいと思います。 御清聴ありがとうございました。

×