Dルートで行こう

ハック日記

Bitcoinの予測、時期について

BItcoinの歴史を学んでいくと、MtGoxの大暴落以降徐々に下がっている傾向にあることが分かった。

 

前日、それを学習データとして加えテストしてみた結果、中々なものだという記事を書いたがそれは間違いだったことが今理解できた。

 

過去900日を学習データ（モデル生成データ）とし、3日分をテストデータとし、予測してみた。予測値として、その日の高値を指定。

 

テストデータの例

@RELATION bitcoin

@ATTRIBUTE Date real
@ATTRIBUTE Open real
@ATTRIBUTE High real
@ATTRIBUTE Low real
@ATTRIBUTE Close real
@ATTRIBUTE Volume1 real
@ATTRIBUTE Volume2 real
@ATTRIBUTE WeightedPrice real


@data

% ?の部分は予測する値

1445007600,?,?,?,?,?,?,?  %275.19 実際の値
1444921200,?,?,?,?,?,?,?  %267.83

1444834800,?,?,?,?,?,?,?  %257.5

 

結果

1.Gaussian 

inst#,actual,predicted,error
1,?,362.32,?
2,?,362.325,?
3,?,362.329,?

 

2.MultiLayer Perceptron

1,?,281.583,?
2,?,281.583,?
3,?,281.583,?

 

ご覧のとおりである。いわばクソ予測となってしまっている。

362$と281$は下落途中の値である。下落途中はBitcoinの歴史からみて中間地点であること。

もうほんとやーだ。

 

じゃあ時間を絞って計測してみよう。

60,30日もクソ結果となってしまったので15日分の測定をしてみる

今度はLow、AttributeをDateとLowだけにして測定してみる。

 

テストデータの例

@RELATION bitcoin
@ATTRIBUTE Date real
@ATTRIBUTE Low real


@data
1445007600,? %258.32
1444921200,? %254.91
1444834800,? %254.5

 

 

結果

1.Gaussian

inst#,actual,predicted,error
1,?,238.895,?
2,?,238.82,?
3,?,238.744,?

 

2.MultiLayer

inst#,actual,predicted,error
1,?,245.127,?
2,?,245.026,?
3,?,244.886,?

 

3.単回帰

inst#,actual,predicted,error
1,?,242.836,?
2,?,242.524,?
3,?,242.211,?

 

今度は近づいた。

しかし、これで自動取引するにはあまりにも怖いぞ。

相関は1にバッチリ、近い。

よく見てみると実際のデータはage続け、予測値も微量ながらage続けている。

これが相関の秘密。実際の値はどうあれ、未来に上げるか下げるかは予測できることになる。

 

FX取引の論文を見て、また勉強を続ける。

 

それはそうと、日にちで相関を求めてもなんも楽しくないしデータとして詳しくないので、15分毎にblockchain.infoのapiからデータを持ってくるプログラムを書いたので

githubに挙げている。

 

https://github.com/pushnanashi/Bitcoin_MashineLearning

 

これから全部プログラムを上げていこうとは思ってます。以上。

 

 

 

 

Bitcoin and Weka by Linux

Linux 上でwekaを動かす。

Linuxもjavaもよくわからない人は絶対先にwindowsGUIのWEKAを実行しまくることをお勧めしたい。

 

wekaのLinuxverをDLし任意の場所に回答（私の場合は/root/）

javaのクラスパスを変えたくない人は以下のように実行

 

java -cp /root/weka-3-7-13/weka.jar  weka.classifiers.trees.J48 -t /root/weka-3-7-13/data/credit-g.arff

 

とりあえず意味を説明しておくとweka.classifiers.trees.J48 はおなじみJ48とかいう決定木生成アルゴリズム。

 

-t 訓練データ.arff　weka-3-7-13にはdataフォルダがあり、サンプルがいっぱいある。

要素の関連で決定木が作れないサンプルデータもあるので、3個ぐらい実行できなくてもいつかはできるやつにあたる。

 

 

なんでこんなことやってるかというと、BitcoinデータをPHPで１０毎秒撮ってきて

perlで成形、ARFFへ。そのできたARFFをwekaで解析。この流れを自動化するためである。

 

いっぱい取引所のAPIがあるなかでどれにしようか悩んではいるのだが。。。

 

Bitcoinを機械学習させた結果 　-Bitcoinの予測-

３年分900日を学習データ６００日とテストデータ３００日にわけて検証を行った。

ちな、要素として

Date,Open,High,Low,Close,Volume by bitcoin,Volume by最近,総量

としている。Dateはその日の00:00:00をUNIXTIMEに変換したものであり、High高値の瞬時的時間やLow低値の瞬時的時間を表しているものではない。

 

 

目安として相関係数を用いているCorrelation coefficientとは相関係数のことであり、

1もしくは-1に近ければ近い方が良いとされる。

 

学生なら、ここで打ち止めだろうけど回帰が出たからと行ってモデルで生成した予測とテストが離れてる値なら意味ないぞ。

 

Mean absolute errorとは端的にいえば、予測した値とテストデータの平均誤差である。

指標とすべきはここだと考えよう。

 

まとめとして

Multilayerperseptronは神がかった予測値を出してくれることが証明されたこと。

Multilayer>単純な回帰>その他重回帰となった。

 

これでトランザクション量とredditの定量化、それにもっと時分割したデータがあれば

即座に計算を返せるモデルの完成になると思う。

誰か、分単位秒単位のデータ持ってない？どうさがしても日ごとのしかないんだ…

 

 

以下検証結果

 

1.要素OPENを検証

重回帰分析による解析アルゴリズムが良好、単純回帰分析が極めて有効であることが証明された。

open値においての予測値とテストデータの誤差は大きい。日の開始要素なぞどうでもいいと思うが。。。

 

multilayerperceptron

=== Summary ===

Correlation coefficient 0.9901
Mean absolute error 202.0657
Root mean squared error 224.4878
Relative absolute error 68.8526 %
Root relative squared error 71.3288 %
Coverage of cases (0.95 level) 100 %
Mean rel. region size (0.95 level) 395.6414 %
Total Number of Instances 325

 

gausianprocess

=== Summary ===

Correlation coefficient 0.9901
Mean absolute error 202.0657
Root mean squared error 224.4878
Relative absolute error 68.8526 %
Root relative squared error 71.3288 %
Coverage of cases (0.95 level) 100 %
Mean rel. region size (0.95 level) 395.6414 %
Total Number of Instances 325

 

回帰分析

=== Summary ===

Correlation coefficient 0.9938
Mean absolute error 12.1635
Root mean squared error 34.637
Relative absolute error 4.1446 %
Root relative squared error 11.0056 %
Total Number of Instances 325

 

単純回帰

Correlation coefficient 0.996
Mean absolute error 12.4549
Root mean squared error 27.6223
Relative absolute error 4.2439 %
Root relative squared error 8.7767 %
Total Number of Instances 325

 

2.要素HIGHを検証

重回帰分析による解析アルゴリズムが良好、単純回帰分析が極めて有効であることが証明された。

 

Mean absolute errorが重回帰、単純回帰双方とも良好

 

multilayer
=== Summary ===

Correlation coefficient 0.9963
Mean absolute error 16.5337
Root mean squared error 36.992
Relative absolute error 5.4198 %
Root relative squared error 11.2352 %
Total Number of Instances 325

 

gaussian

=== Summary ===

Correlation coefficient 0.991
Mean absolute error 218.2416
Root mean squared error 241.2132
Relative absolute error 71.5397 %
Root relative squared error 73.2613 %
Coverage of cases (0.95 level) 100 %
Mean rel. region size (0.95 level) 395.0603 %
Total Number of Instances 325

 

線形回帰

=== Summary ===

Correlation coefficient 0.9978
Mean absolute error 7.9046
Root mean squared error 21.6529
Relative absolute error 2.5911 %
Root relative squared error 6.5764 %
Total Number of Instances 325

 

単純線形回帰

=== Summary ===

Correlation coefficient 0.9965
Mean absolute error 12.6861
Root mean squared error 30.7595
Relative absolute error 4.1585 %
Root relative squared error 9.3423 %
Total Number of Instances 325

 

3.要素Lowの検証

gaussian

=== Summary ===

Correlation coefficient 0.9846
Mean absolute error 198.0522
Root mean squared error 223.042
Relative absolute error 70.7828 %
Root relative squared error 74.8572 %
Coverage of cases (0.95 level) 100 %
Mean rel. region size (0.95 level) 394.7339 %
Total Number of Instances 325

 

multilayer


=== Summary ===

Correlation coefficient 0.9938
Mean absolute error 17.6348
Root mean squared error 35.4825
Relative absolute error 6.3026 %
Root relative squared error 11.9086 %
Total Number of Instances 325

 

線形回帰


=== Summary ===

Correlation coefficient 0.9905
Mean absolute error 18.0418
Root mean squared error 43.6163
Relative absolute error 6.4481 %
Root relative squared error 14.6385 %
Total Number of Instances 325

 

単純回帰


=== Summary ===

Correlation coefficient 0.9914
Mean absolute error 15.4175
Root mean squared error 42.1579
Relative absolute error 5.5101 %
Root relative squared error 14.149 %
Total Number of Instances 325

 

 

スパムメールの時系列分析が全く相関がでず進んでない中、こんな簡単に拾えるデータで相関が出てるのは誠に悔しい死にたい。

それと、APIである程度トランザクションを掘れ、毎秒スクリプト回せば分単位の値段もわかる。

これを使って、予測サイトを作ろうと思ってる。

僕が市場を動かすんだ！

 

Bitcoinを予測する際の要素検証

引用「Bayesian regression and Bitcoin」ベイズ回帰とBitcoin

http://arxiv.org/pdf/1410.1231.pdf

・twitter

・重み付き多数決

・時間を3分割した中で各時間トップ６０のトレーダーを注目

 

数式はそもそも見なくていい。ベイズも適当に回帰線として考えておけばいいとして

twitterで市場のワードを集積している。私の意見としてはTwitterは以上にスパムが多く、スパムの雑音を外したところで書き込みが極端に少ない。

重みつき多数決とは、Bitcoin市場を引っ張る売り買いの量である。

大量売り（拒否）があれば、それがたとえ一回でも市場に波乱を起こすものであり、

少額の取引はあまり市場に波及をもたらさない。

つまり、拒否権賛成権にBitcoinという重みをつけている。それに市場がつられ起爆となる。

昨日、アホみたいに市場が下げたことがあったがそれは一人がやったことで市場が付いてきていないケースもある。まだ始めたばかりなので、こういうのがなんども続ければ一変数として加えることもあるかもしれない。

 

 

Bitcoinの機械学習って未発達ってところじゃねえな

諸事情で海外サーバを借りるため１マンほどBitcoinに突っ込んで

7500円ほどをBitcoinに監禁したまま放置してた。当時レートで27500円。

今みたら結構高騰してて30500円で、すぐ売った。

なんか知らんが8200円になったという話。

 

気になったので検索して調べてみるとbitcoinを統計学的、機械学習的に取り扱っているのは「処理のトランザクションを総合的にみて、悪意のあるBitcoinの使い方をしているユーザを割り出す研究」ばかりが出てくる。

実は、ここ数ヶ月でホットな話題なのだが私としてはどうでもいい世界だ。

株みたいに自動取引software作って、売買してる人が見つからんのだ。

金儲け好きで開発者だらけの市場でなんでないのかわからんというところ。

（多分だが普通に非公開なだけだと思うw）

 

株みたいに変数にしにくいニュース決済事件汚職…社員のやらかしなどなど色々あるが

Bitcoinは数値と、某取引所みたいな事件しかないわけだ。つまり時間とトランザクション処理（売り買い）を変数にすればいいだけの話である。

海外の取引所は入金が面倒だったり、そもそも換金手続きがうんこだったりするわけで

そうなれば、日本の取引所を使うことになると思う。

 

日本の取引所は国際取引所に引っ張られるケースがほとんどであり、相関はあると思う。

もちろん市井の声もあるだろう、誰か忘れたが研究でグーグル検索数とBitcoinの上がりねは相関しているという論文が出されたばかりだ。

 

非常に数値化しやすいではないか。ほとんど人間が触らなくていい。

 

 

と、何かと真面目に言ってますが、基本情報も受からないクズですからね。

勉強して受からないなら可愛げがありますが。申し込んで勉強すらしないクズです。

 

基本情報と卒検が終わればこのBitcoin予測のサイトでも立ててみようかと思います。

わかりやすくWekaのやつでやってみようかな。

 

あと、考えているのはBitcoinの仮想市場サイトを作ることです。つまり、Bitcoin体験サイトを作るということ。

仮想通貨の市場をさらに仮想化し、なんちゃってBitcoin取引サイトを構想中です。

ずっとやってみたかったんですが、なかなか時間がない。。。

 

こちらはアホみたいに計算処理して返さないといけないと思うので、安物のVPSで耐えられるかですがね。

 

仮にそういうサイト作ったところで全部オープンソースにすると思います。

 

 

以上

R言語…しゅごい

R言語マニュアル

https://cran.r-project.org/doc/contrib/manuals-jp/Mase-Rstatman.pdf

 

wekaでは統計学の真似事しかできず、細かい値が分からないのでR言語をやらないといけない。

Rには一応RwekaというものがありWekaれることも確認。

 

 

・Wekaった結果

spam ham で単に分けてみる。メールはあげられないけどARFFぐらいはどっかのアップローダ使ってアップしてみようかな

使用アルゴリズム

1.Multilayerperceptron　99.732

2.J48　　　　　　　　100.000

3.RepTree　　　　　　100.000

4.BayesNet　　　　　　99.911

5.Logistic　　　　　　　78.3036

 

ロジスティク回帰以外は良好。ロジスティックの目的変数は２つあれば解析でき、spamhamの目的変数を撮るARFFはいい感じに分類されると思っていたが、そうはならなかった。

 

ここからが問題でwekaで時間予測する。

モデルを与えて,

Arff を時系列順に並び替え、それを 3 分割し た。先頭2部はモデル生成の ARFF とし、後尾1部はテストデータとして解析する。（例として元３０００通、モデル２０００通、テスト１０００通）2008 年 2 月半ばから 2010 年 3 月までのメールを解析するデータとした.

 

 

 

しゅごくゴミです。。。

目的変数Unixtime  説明変数11 個

 

使用アルゴリズム

 

1.Multilayerperceptron

Correlation coefficient -0.0513

Mean absolute error 13799602.723

Root mean squared error 14940678.406

Relative absolute error 64.0257 %

Root relative squared error 69.028 %

 

2.GausianProcess

Correlation coefficient -0.0188

Mean absolute error 17201100.4342

Root mean squared error 17362248.6297

Relative absolute error 79.8075 %

Root relative squared error 80.216 %

Coverage of cases (0.95 level) 100 %

Mean rel. region size (0.95 level) 392.8374 %

 

3.SMOreg Correlation coefficient -0.0218

Mean absolute error 17469945.5814

Root mean squared error 17660912.5654

Relative absolute error 81.0549 %

Root relative squared error 81.5959 %

 

時間の相関 2 変数を時間と IP と spamham の３つにした。どうやら関係ないどころか、期待に反して悪化 している。

 

1.SMOreg

Correlation coefficient -0.0014

Mean absolute error 23064370.1931

Root mean squared error 23157477.9568

Relative absolute error 107.0112 %

Root relative squared error 106.9908 %

 

wekaが問題なの？実は半分正解である。

時間を予測するのではなく、ある時間にあるスパムメールがくることが目的としなければならず、wekaではそれができない。できない！

 

そしてR言語に頼るのである。

R？やだーめんどくさいじゃないですかー。と最初に貼ったリファレンスpdfを見ると、なんとスッキリしていることだろうか。。。

Cでもある程度は組めるが、本当に無駄な作業が多くなる。（PG量が増える）

 

決定木の予測としてはpredict.treeを使える。もちろん、モデルとテストデータに分けてモデルで予測した値をテストデータと相関やらなんやら比べることもできる

 

>even.n<-2*(1:75)-1

>train.data<-iris[even.n,]

>test.data<-iris[-even.n,-5]

>iris.lab<-factor(c(rep("S",25),rep("C",25),rep("V",25)))

>train.data[,5]<-iris.lab

>iris.rp2<-rpart(Species~.,train.data)

>plotcp(iris.rp2)

 

Brownleeの排気損失率データ　（同志社大）

 

CRANパッケージ見ると離散時間生存木とかもあるみたいだー

スパムハムを離散時間にするって意味わからんけど

後輩が力作を作ってきた件

今、ユーザがAIを組みそれを戦わせる対戦ゲームをチームで開発中ですが、

Web,DB担当の私は正直物足りない担当でした。

 

なのでかなり放置をしてたのですが、後輩が紹介ムービーを作ってきたので見たら

超力作で「ホゲー」と思ってしまった。

 

急ピッチでできていないところを改変してます。

明日は内定式だぞ！

だぞ！

基本情報持ってないから受験しなさいって言われて

勉強してないですなんて言えないから

 

「もうバッチりんごっっっっw」って行ってしまってるぞ

 

こちとら卒論で忙しいんじゃ！

人の研究をみて思った事

後輩にマルウェア感染後DNS問い合わせによってマルウェアの挙動を察知する

みたいな研究をやっている人がいたが

「HTTP　でPOST GET　みれば？？？」とケチをつけそうになった。

 

HTTPbotnetとかはPOST挙動を見ていくとすぐにわかるし(たいてい Gate.php　にPOST投げてる)

 

DNSもそうだけどHTTPリクエストの方向も相当研究進んでるから

今更って感じがした。

Crypterを解析し、自分のCrypterを作成する話 1

Crypterとは犯罪者であるハッカーが作成したマルウェアなどをアンチウイルスソフトに検知させないため行う、暗号化支援ソフトである。

 

大まかに　Webベースとソフトウェア型に分かれており

機能としては暗号化/AntiVM/icon change/リバースエンジニアリング対策/など

多岐に渡る。

 

実際にウィルスを投げ込み使ってみた感触としては、ウィルスによっては反応しなくなったり、ちゃんと反応したりとまちまちだが、

ちゃんと反応したウィルスは半分以上の効率でアンチウイルスソフトにかからなくなっている。

 

webベースのものは

・有料版

fudPE Crypt Service　など

・無料版有料版

https://msil.pw/　など

 

がある。

今回作成しようと思ったのはソフトウェア型なのでwebベースは放置の方向で。

 

なぜCrypterを解析しCrypterを作ろうと思ったかという点には、先に言った試したCrypterは無料版であり、動くものと動かないものがあったというところに来る

なぜ動かないのか、そもそもなぜアンチウイルスソフトが反応をしなくなるのか

を知りたくなったからだ。

 

あ、犯罪目的ではないことをここに明記しておく。

お勉強目的です！

 

コードの公開も考えておりますが、その点は犯罪になるのかな？法律のお勉強も重ねないとな。

 

とりあえずVBのCrypterコードを友人から貰ったのでそのものをベースにして

お勉強します

 

では。

愚痴（メモ）

今やっていることについてのまとめ

IPがホスティングIPでなくshared IPのため、ホスティングIPにする。

先行研究のUnixTimeの計算が大幅に間違っているためそれを修正し、arffに追加

 

とりあえず、なぜ時系列に着目するかだけを書き記す。

今までの解析法だと時系列には着目されておらず、文章解析などが主流である。

時系列を機械学習で扱っているものはネットワーク異常検知など時系列単体で

解析を行っているものであり、あっても時系列を含め１−４の変数を含む解析であることは間違いない。

 

スパム解析がなぜ時系列に注目しなかったかというと「文章解析」に力を入れる方がより良いからである。

なおかつ、スパマーのIPやネットワークの監視をする方が効果は得られやすい。

ただ文章メインになった場合ある時文章の破壊的革新が起きてしまえば、

文章解析のノウハウ蓄積が意味を為さなくなる。

時系列の視点を加え解析することにより、株価予想や天気予報などの解析と同じく来るスパマーの攻撃に耐えるものを考えたい。

 

と、スパマー予備軍である私の研究内容

make_kaiseki_data

大まかな概要と出力ファイル、使用プログラムを記載

使用プログラムと出力ファイルは出現順に並んでいるものとする。

 

make_kaiseki_data.csh

ip.pl

cat $z |perl make_matching_table.pl

maildir下にあるmailをmake_matching_table.plに投げる

time_table_plain　にmailファイル名を出力

 

"making matching table..."

 table_sort.pl

（subject_table_plain from_table_plain time_table_plain をtable_sort/.plに渡す）

 

"rename mail data..."

rename フォルダを作成

rename.pl

ip_data_sort.pl

 

"making data"

renamedir下にあるファイル名を kaiseki_data_header kaiseki_data_len　に出力

renamedir下にあるファイル名をmake_data_header.plに渡す

renamedir下にあるファイル名をmake_data_body.plに渡す

 

 

"making data sc..."

make_data_body_sc.csh

 

"making maiseki data...."

make_kaiseki_data.pl

 

mv (renameとbodyとtmp_bodyをoutput_dataに移動　*_plainとkaiseki_data_*とip_data_renameとip_rename_sorted をoutput_data直下に移動)

mv(*_tableをoutput_data/table/に移動)

find(output_data/tmp_body/base64_6*の空ファイルを削除)

find(output_data/tmp_body/decode_base64_6*の空ファイルを削除)

 

find(output_data/tmp_body/quoted_6*の空ファイルを削除)

find(output_data/tmp_body/tmp_base64_6*の空ファイルを削除)

rm(output_data/tmp_body/tmp_base64*_6を削除)

"finished"

 

ip.pl

ipを出力

maildir.csvを弄る

maildir下にあるディレクトリ名を取得する

dir名,spam（s-1,spam　など）

 

spamの場合の処理

ip_table_plainにはipを出力

ip_dataにはfullpathとipを出力

hamの場合の処理も同様？？？

 

make_matching_table.pl

題名と送信者とUNIX時間の抽出

subject_table_plainにsubjectを出力

from_table_plainにfromを出力

time_table_plainにtimeを出力(UNIX TIMEに変換)

 

table_sort.pl

subject_table_plainをソートしsubject_tableに出力

from_table_plainをソートしfrom_tableに出力

time_table_plainをソートしtime_tableに出力

ip_table_painをソートしip_tableに出力

 

rename.pl

time_tableの中身のファイル名を抜き取り行順を$iとし

$i,ファイル名をname_tableとして出力

ip_dataの中身をname_tableの順番でipを並べてip_data_renameに出力

 

ip_data_sort.pl

ip_data_renameを昇順？にしてソートしてip_rename_sortedを出力

 

make_data_header.pl(よくわからない)

mailのheaderから情報を抜く

subjectcountに20001を足してるsubject_numberとする

formには30001を足してfrom numberとする

 

Message-ID　Content-type を抽出しfrom とMessage-IDを比較して一致度を測る。

テキスト形式の抜粋、添付の有無を抽出

 

Message-IDとfromの一致度,kaiseki_data_header、subjectのマッチングNO,fromのマッチングno、テキスト形式、添付の有無　をkaiseki_data_headerに出力

 

make_data_body.pl

content-length 文章の長さを測る

kaiseki_data_lenに出力する

 

make_data_body_sc.csh

renamedirのmailをutf8に変換し、rename_utf8に置く

kaiseki_word.pl

make_data_sc.plを呼んでスパム語とスパム単語、総スパム語byte数をkaiseki_data_scに出力

hit_words.datにf1とf2シソーラスワードを出力

make_data_body_http.plでURL個数、httpbyte数をhttp_lenに出力

make_data_per.plの呼び出し

 

base_64_* decode_* qupted_* tmp_base64_* rename_utf8/ body_words http_len kaiseki_data_sc をtmp_bodyに移動

 

 

make_data_body_http.plでURL個数、httpbyte数をhttp_lenに出力

 

-kaiseki_word.pl

titleと本文をtmpに移しつつbody_$iに移管

 

-make_data_sc.pl

スパム語とスパム単語、総スパム語byte数をkaiseki_data_scに出力

 

-make_data_body_http.pl

URL個数、httpbyte数をhttp_lenに出力

 

-make_data_per.pl

rename後のファイル名、URL個数、URL出現率、スパム単語の出現率をkaiseki_data_bodyに出力

 

make_kaiseki_data.pl

kaiseki_data.arffを作成

ip_num,message_ID,$subject,$from,text_type,multipart(添付),url個数,urlbyte数,spam頻出,spam度数、スパム・非スパム（今中さんのp8-p9 2.4.1 数値として扱う入力属性を参照）

 

以上、抜けもれあるかも

Torの中継を政治値を加えて中継していくのってどうなん？

ずっと思ってたんだけど、単に繋いでいくってアホらしくない？

中継node数n個だと考えて

 

 

俺（うんこ）->Tor1 -> Tor2 -> ... ->Tor(n) ->目的サイト

 

政治的側面を備えた値を付与して、目的サイトにとって仲の悪い国に中継していってほしいなと思った。

 

例えば目的サイトがインドだった場合、出口であるTor(n)と次にTor(n-1)に中国とパキスタンを持ってくる。

仮にnに中国、n-1にパキスタンだとしてn-2アフガニスタンn-3はアメリカ。。。

とか。

インドと中国、パキスタンは仲悪い

パキスタンとアフガン、アメリカは仲悪い

みたいに繋いでいってほしいなと思いました（ぶちぎれ）

 

国家が何年か続けばもちろん仲の悪い国も出てくる。それを利用すれば？って話。

 

でも多分だけど、仲の悪い同士は通信監視しあってるので

nの出口nodeだけはインドと仲のいい国にしていして、その仲のいい国とインドと仲悪い国をn-1 n-2に持っていってもいいんじゃないかと思いました（ぶちぎれ）