RPC Lab - Karl-Johan Alm 2017 Digital Garage. All rights reserved. Redistribution or public display not permitted without written permissio

Size: px

Start display at page:

ひでかうとだ
5 years ago
Views:

RPC アプリの作成 @DG Lab - Karl-Johan Alm 2017 Digital Garage. All rights reserved.

2 このセッションについて RPCアプリの作成 : 注意点とベストプラクティス ( 前半 ) RPCのコードを触ろう RPCアプリの作成 : 注意点とベストプラクティス ( 後半 ) ダウンロード版 : 2

3 Slack のチャネルについて RPCアプリ作成の相談や質問の為のチャネル :#rpc-app 1 CHANNELSをクリック 2 #rpc-appをクリック 3 Join Channelをクリック 3

4 Agenda 環境 Confirmations, reorgs (reorganizations) 脅威モデル RPCアプリの流れ(invoice 支払問題点) 演習(Task 1 3) 4

5 環境 5

6 ポート Bitcoin Core: 1 P2P (main net は 8333 BC2 では 8444) 2 RPC (main net は 8332 BC2 では 18442) 6

7 RPC と P2P との違い RPCアクセス=ウォレットに無制限のアクセスアクセスを与える= 自分の財布を相手に渡す! 自分のアプリをApp Storeに出してアプリからRPCで繋いでという考えは無論駄目! 7

8 正しい RPC アプリの構成法 8

9 正しい RPC アプリの構成法 1 フルノードを安全な状態に設定する 2 そのノードと接続する RPC アプリを作成しノードと同じサーバーに入れる 3 その RPC アプリにサーバー外と接続する機能を追加する 4 ユーザーが使うアプリを 3 を通して作成する 9

10 正しい RPC アプリの構成法 1 フルノードを安全な状態に設定する 2 そのノードと接続する RPC アプリを作成しノードと同じサーバーに入れる 3 その RPC アプリにサーバー外と接続する機能を追加する 4 ユーザーが使うアプリを 3 を通して作成する 10

11 RPC の使用制限原則 localhost 以外のホストからのアクセスは却下 RPC アプリが認証情報を指定する方法は以下の二つ : 1 設定ファイル (bitcoin.conf) に記述してそのディレクトリを指定する :-datadir=x 2 直接指定する :-rpcuser=y -rpcpassword=z 11

12 RPC アプリここでは2 つまりrpcuser/rpcpasswordを使うそのため bitcoin.confを作る必要がある再掲 ( デフォルト ) Mac: ~/Library/Application Support/Bitcoin/bitcoin.conf *nix: ~/.bitcoin/bitcoin.conf 12

13 RPC アプリ bitcoin.conf の内容 : rpcuser=user rpcpassword=password 注意 : このイベントでは password というパスワードを使うが通常は安全なパスワードにしよう 13

14 RPC アプリ保存したら bitcoind を再起動する必要がある 1./bitcoind を実行したターミナルで ^C(Ctrl+C) を押す見つからなかったら killall -9 bitcoind で全ての bitcoind が消えるマイニングしていると停止するまでに時間が掛かる可能性がある 2./bitcoind -printtoconsole をもう一度入力する 14

15 RPC アプリシンプルなCLIオンリーのシステム実装する機能 : invoiceの作成支払の確認ダブルスペンド reorgなどの対策 15

16 RPC アプリ環境は node.js bcrpc という bitcoin-rpc ラッパーを使う bitcointest という bitcoin テストスイートを使うあまり時間がないので bitcoin に関係ないところを全て入れてあるバージョンを以下に用意した : bc2/conference/rpc-cli 16

17 RPC アプリ必要なライブラリのインストールと RPC アプリの起動 : $ cd bc2/conference/rpc-cli $ npm install $./rpc-cli Available commands: [...] 17

18 RPC アプリの開発ツール (npm test) テストスイートの起動 : $ npm test > rpc-cli@1.0.0 test../bc2/conference/rpc-cli > mocha tests.js db can be connected to bitcoind can be found bitcointest configures 18

19 Confirmations, reorgs 19

20 Confirmations Block 123: Tx acf (coinbase), tx 27c, tx [...]

21 Confirmations 27c の confirmations = 1 Block 123: Tx acf (coinbase), tx 27c, tx [...]

22 Confirmations Block 124: [...] 27c の confirmations = 2 Block 123: Tx acf (coinbase), tx 27c, tx [...]

23 Confirmations Block 125: [...] Block 124: [...] 27c の confirmations = 3 Block 123: Tx acf (coinbase), tx 27c, tx [...]

24 Reorg 123 が同時に作成された場合 Block 123a: [...], tx 27c, tx [...] Block 123b: [...] Block 122:

25 Reorg 123 が同時に作成された場合 27c の confirmations = 1 27c の confirmations = 0 Block 123a: [...], tx 27c, tx [...] Block 123b: [...] Block 122:

26 Reorg Block 124a: [...] 27c の confirmations = 2 a チェーンが先に伸びた場合 27c の confirmations = 0 Block 123a: [...], tx 27c, tx [...] Block 123b: [...] Block 122:

27 Reorg b チェーンが先に伸びた場合 27c の confirmations = 1 27c の confirmations = 1 Block 124b: [...], tx 27c, [...] Block 123a: [...], tx 27c, tx [...] Block 123b: [...] Block 122:

28 Reorg 124 も同時に作成された場合 27c の confirmations = 1 Block 124a: 27c の confirmations = 2 Block 124b: [...], tx 27c, [...] Block 123a: [...], tx 27c, tx [...] Block 123b: [...] Block 122:

29 Reorg TX 27c: - txin: - hash = index = 0 - txout: - addr = 1abc TX 45e: - txin: - hash = 356 TX 27e: txin = tx index = 0 TX 45e: txin = tx txout: as - diagram addr = 1def

30 Reorg ダブルスペンドの場合 45e の confirmations = -1 27c の confirmations = -1 27c の confirmations = 1 45e の confirmations = 1 Block 123a: [...], tx 27c, tx [...] Block 123b: [...], tx 45e, [...] Block 122:

31 Reorg ダブルスペンドの場合 27c の confirmations = 1 45e の confirmations = 2 27c の confirmations = -2 Block 124b: [...] Block 123a: [...], tx 27c, tx [...] Block 123b: [...], tx 45e, [...] Block 122:

32 脅威モデル 32

33 とりあえず敵を知れ POCやプロトタイプの開発ではあまり気にしない方が良いどこが駄目でどう解決すれば良いか分かれば充分最初からあらゆる問題を対応しようとするのは無理! とりあえず敵を知る事

34 環境の例えカジノでコイントスをやるか決める : 表なら2 万円をWIN 裏なら1 万円をLOSE 国が造幣した硬貨かカジノが造幣したコインかで変わるビットコイン開発が似たような状況である

35 ブロックチェーン上の脅威モデル一般のソフト開発と異なる部分がいくつかあるきちんと理解せずに開発すると問題が起きる可能性が充分にある万一というレベルの話ではない今現在全く安全ではないソフトが世の中に溢れている! 35

36 脅威モデルシビルアタック (Sybil Attack)

37 カジノでポーカーに参加する普通 : ディーラー以外の参加者は自分の為に行動を取る

38 カジノでポーカーに参加する但し自分以外の人は皆カジノに雇われた人なら?

39 ビットコインネットの場合

40 シビル攻撃 (Sybil Attack) 種類一つのノードを攻撃するネットを完全に分割させるネットを部分的に分割させる 40

41 シビル攻撃 (Sybil Attack) 方法スロットを使い切る大量のノードを建てる MITM(Man In The Middle) ファイバーの接続切断 41

42 シビル攻撃 (Sybil Attack) 防止 networkhashps が下がると怪しい複数ノードを複数の場所に建てて信用するノードとしか接続しない出来れば VPN を通して BIP-150 (Peer Authentication) 42

43 脅威モデルダブルスペンド

44 Cheque( 小切手 ) に例える 3 万円の小切手を 2 万円が入っている口座に送信する依頼を入れる併せて 5 万円を持っていると思うすぐ後 3 万円を引き出すがその後小切手が却下されて口座のバランスがー 1 万円に

45 Cheque( 小切手 ) に例える小切手が確認されてから使えば問題ないビットコインも同じ

46 ダブルスペンド BTC を貰った様にみえるのに実は貰っていない例 : 低い目の fee の tx と高い目の fee の tx を作成前半をターゲットに送信確認された時点で後半をネットに送信 ( 実にあった例 )

47 ダブルスペンド展性によるダブルスペンド : tx1 tx2 tx3( 繋がっている 0-conf 使用 ) tx1のハッシュを変えるとtx2 tx3が駄目になる誰でも出来る( マイナーリレーノード ) (segwitが解決する)

48 ダブルスペンドユーザーのウォレットソフトがクラッシュ既に使われたUTXOをもう一度使おうとすることがあり得る RBF(Replace By Fee) 結局 :txの価値によって安全程度を決める事

49 ダブルスペンド ( シビルアタック下 ) 本物の tx をターゲットに送信しない本物の tx が入っているブロックを送信しない偽物 tx をターゲットにしか見せない

50 脅威モデルビジネスロジックの問題

51 ビジネスロジックの問題安全じゃない環境秘密鍵のアクセス (Bitfinex ウォレット ) 不可分 (atomic) 実行 Web wallet の Submit 問題プログラマーエラーランダムではないランダム (nonce を二回以上使う等 )

52 脅威モデル確認信用

53 確認信用 SPV ウォレットブロックエクスプローラー

54 脅威モデル暗号化の破綻

55 暗号化の破綻 EC の弱点 Address reuse やばい EC が完全に破綻しても pub key hash しかなければそれでも bitcoin を安全にさせる方法がある (hash algo が破られない限り ( 低可能性 ))

56 脅威モデルコンセンサス問題

57 コンセンサス問題ネットがフォークしてしまう時の話例 :BIP-66(PPCOIN) 複数のノードを複数の場所に置き賛成する事を確認すれば問題ない複数バージョンを同時に使うフォークが起きた場合両方のフォークの上で全ての tx を同時に送信

58 RPC アプリの流れ 58

59 RPC アプリの流れ (invoice) invoice システムノードを作成する会社がアプリで以下の情報を含む invoice を発行する invoice number bitcoin address( ここに払ってもらう ) amount( 払ってもらう金額 ) content( 払ってもらう理由 - 品目など ) 59

60 RPC アプリの流れ (invoice) 具体的には : 1 bitcoin.getnewaddress から addr を入手する 2 db の invoice に addr, amount, content を insert する 60

61 RPC アプリの流れ ( 支払 ) Invoice に付いている bitcoin address(addr) に誰かが bitcoin を送った時にその tx を記録するこれを payment として DB に追加する db.payment.insert({txid,addr,invoice,amount}) 既に記録している txid の場合は更新する 61

62 RPC アプリの流れ ( 支払 ) Payment に変化があった場合 (create/update) invoice のステータス ( 未入金一部入金など ) を更新する if sum(payment.amount) = 0 unpaid if sum(payment.amount) = invoice.amount paid if sum(payment.amount) < invoice.amount partial if sum(payment.amount) > invoice.amount overpaid... 62

63 RPC アプリの流れここまでのおさらい : 1 invoice に bitcoin address (addr) を付ける 2 支払先が addr の tx を見つけたら payment として記録する 3 sum(payment.amount) = invoice.amount だと paid( 入金済 ) として認める 63

64 RPC アプリの流れこれだけだと問題が複数あるどんな問題が起き得るか 1 分考えよう 64

65 RPC アプリの流れ ( 問題 ) 問題の一つはダブルスペンドというもの 1 tx を作成 out を invoice の addr に 2 tx をコピー out を自分の wallet にまずは 1 をターゲットに送信し確認された時点で 2 を他のノードに送信 RPC アプリは 1 を見た時点で paid に 2 は無視 65

66 RPC アプリの流れ ( 問題 ) もう一つのダブルスペンド 1 tx 作成 out=addr amount=invoice.amount/2 2 txをコピー hexを変える 1を送信し確認されたら2を送信するアプリはinvoice.amount/2を二回払われたと間違える 66

67 RPC アプリの流れ ( 問題 ) 他にもあるがとにかく確認されたか未確認であるかを考えて開発する必要がある Pending = 未確認 = ( 適当 ) 5 ブロック以下 Confirmed = 確認された = ( 適当 )6 ブロック以上 paid, pending_paid, partial, pending_partial,... 67

68 Task 1 68

69 Task 1 場所 :payments.js, 25 行目 (createinvoice) 内容 :model.invoice の作成詳細 : 関数の足りない部分を補う ( 具体的には bitcoin address を獲得しそれを invoice の DB に登録する ) ヒント : 非同期プログラミングを調べるとやり易くなる ( 追加書類.pdf を参考に ) 69

70 Task 1 リファレンス実装では 5 行 (4 ステップ ) テスト (npm test) で PASS すること (13/40 22/40): Invoice can be created reorg unconfirm then... / double spend (replace...): can create an invoice can pay an invoice double spend replace (payment to same address): submits invoice 70

71 Task 1 Task 1 が完了すれば rpc-cli というコマンドで invoice を作る事ができるようになる $./rpc-cli create 5 " 靴下 " $./rpc-cli list invoice: amount: status: conf: pending: 587ca8535a1e f5df9 5??? 0 BTC 0 BTC でも rpc-cli info 587ca はまだできない 71

72 Task 2 72

73 Task 2 場所 :payments.js, ~100 行目 (updateinvoice) 内容 :paymentの対応詳細 :paymentの確認と total/final/disabledamountの計算 ( 上の方に変数がある ) 73

74 Task 2 リファレンス実装では 25 行 (13 ステップ ) テスト (npm test) で PASS すること (22/40 25/40) ヒント 1:reorg が発生した場合以下が必要 : model.payment.setstatus(payment._id, 'reorg', (err) => { model.history.create(invoice._id, payment._id, { action: 'reorg',... 74

75 Task 2 ヒント 2:reorg が発生したかどうかは tx がブロックに入っているかどうかで分かるそして transaction.blockhash が null であればその tx はブロックに入っていないということになる! 75

76 Task 3 ヒント :( 過不足なく ) 丁度支払ったという事を Math.abs( 支払った金額 - 要求した金額 ) < config.thresholdsatoshi というように確かめる 76

77 Task 3 77

78 Task 3 場所 :payments.js, ~140 行目 (updateinvoice) 内容 :invoice のアップデート詳細 : ここまでに確認集計した payment の情報を元に invoice をアップデートする 78

79 Task 3 リファレンス実装では 23 行 (21 ステップ ) テスト (npm test) で PASS すること (25/40 40/40) 79

80 bitcointest について bitcointestはノードを作ったり消したりする大抵うまく動作するが稀にプロセスが残ることもある bitcointestというテストが駄目だったりしたら $ killall -9 bitcoind で直るが 80

81 bitcointest についてこれでは全ての bitcoind のプロセスが殺される bitcointest のプロセスを個別に指定するなら : $ ps -A grep bitcoind でリストを見て /../src//bitcoind -regtest -datadir=/tmp/bitcointest// rpcuser=user というようなノードの PID(11453) を kill -9 に渡す 81

82 ヒント等全てのスライドはで落とせる node.js に自信の無い方は 0103_ 追加書類.pdf を参考にすると良いチームを組んでやることをおすすめする 82

83 ヒント等 npm test が実行するテストのソースコード (tests.js) を見れば何が駄目か明確になるかもしれない TASK=1 npm test とすると Task 1 のテストだけが実行される同じく 1 を 2, 3 にすると TASK 2, 3 になる 83

84 ヒント等 V=1 npm test ではテストが出力する情報が増える DEBUG=bc2 npm test では RPC アプリの debug() が表示されるこれらは同時に指定できる : $ V=1 DEBUG=bc2 npm test DB をリセットしたい時 ( 全てが消える!!!): $ mongo --eval "db.dropdatabase()" 84

85 ヒント等はまったら遠慮無く #rpc-app にて質問をしたり私たちに直接聞いたりして下さい頑張って下さい! 85

86 @DG Lab - Karl-Johan Alm 86

RPC Lab - Karl-Johan Alm 2017 Digital Garage. All rights reserved. Redistribution or public display not permitted without written permissio

RPC Lab - Karl-Johan Alm 2017 Digital Garage. All rights reserved. Redistribution or public display not permitted without written permissio RPC アプリの作成 @DG Lab - Karl-Johan Alm 2017 Digital Garage. All rights reserved. Redistribution or public display not permitted without written permission from Digital Garage. このセッションについて 0104. RPCアプリの作成