モナコインをマイニングしたのでメモ( Windows , Ubuntu )
マイニング知識ゼロからモナコインマイニングに挑戦したのでメモ。
ネット上の記事を調べたところ、以下の手順を踏めばとりあえずマイニングができました
①プールに登録する
②マイナーツールをインストールして実行する
- Windowsの場合はインストールして実行するだけ
- Linuxの場合はマイナーツールをビルドして実行
今回は両者ともccminerというツールをインストールしました。
環境
WindowsとLinuxのデスクトップを持っているので両方でマイニングします
Windows 10 , Geforce GTX1050 ti
Ubuntu 17.04 , Geforce GTX1060
プールに登録する
マイニングをするためには、ソロで行うかプールに加入して行うかの2パターンがあるが
試しにマイニングするので、敷居が低そうなプールに加入してマイニングすることにしました。
VIP Poolに登録しました。
VIP Pool - Monacoin採掘所 - Home
プールに登録する方法は以下を参照しました
モナコインウォレットが必要になります
monacoin-crypto.blogspot.jp
アカウントを作成すると、ワーカーを追加することができます
このワーカーのidとパスワードを後述するツールと紐付けます
Windowsでマイニングする
Windowsでccminerをインストールする手順は以下を参考にしました
freely-life.com
Linuxでマイニングする
Linuxでccminerをビルド・インストールする手順は以下を参考にしました
leopard-fishing.com
ccminerをビルドしたときの備忘録
簡単にはビルドできませんでした…
原因は以下です。
- 最新版のcudaではビルドできないっぽい
2018/01/04時点で最新のcudaは9.1でしたが、ビルドできませんでした。
8.0をインストールし直しました。
以下の記事に解決策が記載されています。
マイニング/UbuntuとGPU(NVIDIA)でMonaコインをマイニングしてみる - 仮想通貨(暗号通貨)メモ
- gccのバージョンが5.0以上だとビルドできない
4.9に変更しました。
以下の記事を参考にしました。
UBUNTUにXRDPしてNVIDIAのグラボを使ってモナコインマイニング | AC-5
- anaconda環境だとうまくビルドできない
よくわかりませんが、以下のようなエラーがでてビルドできませんでした
anaconda環境にgccをインストールするとビルドできるようになりました
github.com
その他
AskMonaにモナコインのマイニングに関する情報がありそうです
askmona.org
【bitFlyer API】特殊注文まとめ
特殊注文とは?そのメリット
bitFlyerの特殊注文とは、「注文種別」・「執行条件」・「執行数量条件」というオプションを選択することができるタイプの注文です。下記、公式参考。
ビットコイン取引所【bitFlyer Lightning】
例えば、注文種別には以下の種類があります。(公式から引用)
IFD(If Done):一度に2つの注文を出して最初の注文が約定したら2つめの注文が自動的に発注される注文パターンです。
OCO( One-Cancels-the-Other order):2つの注文を同時に出して一方の注文が成立した際にもう一方の注文が自動的にキャンセルされる注文パターンです。
IFDOCO:IFDとOCOの組み合わせで、IFD注文が約定した後に自動的にOCO注文が発注される注文パターンです。
というように一度に複数の注文がだせます。
この特殊注文に目をつけた理由としては、
・遅延対策に有効なのでは?
・スキャルピング等、利確・損切にスピードが求められるときに有効なのでは?
・ポジションとして管理したいときに便利では?
と思ったからですが、使いようはいろいろあるかと思います。
今回はAPIを使って特殊注文する際に、調査してわかったtipsを記事として残します。
なお、pybitFlyerを使用しています。
GitHub - yagays/pybitflyer: Python wrapper for bitFlyer's REST API.
特殊注文(親注文)を新規で送る
pybitFlyerで特殊注文を送ります。
APIでは特殊注文のことを親注文と言ったりしているようです。
「親」というのは、単体の注文を「子注文」とするとIFDやOCOなど複数の注文がセットになった注文を親注文とするからみたいです。
注文例としてIFDOCOを注文します。
IFD:指値で買い注文、約定したらOCO注文 OCO:①、②のいずれかの注文が約定したら片方の注文をキャンセルする。 ①指値で売り注文(利確) ②ストップ注文、トリガー価格を下回ったら成行で注文(損切)
用いる関数は、sendparentorder()です。
ここでの引数は、
sendparentorder( order_method = 'IFDOCO' #注文種別 minute_to_expire = '100' #親注文の有効期限(分) time_in_force = 'GTC' #執行数量条件 parameters = [ order1, order2, order3] #子注文の情報 )
となります。
parametersには、子注文の情報をlist形式で渡します。今回のIFDOCO注文では、子注文が3つなので、[ {注文①},{注文②},{注文③}] というようになります。
また、ここで気をつけたいのが、minute_to_expireが親注文の有効期間であること。
最初の注文が約定したあとに、minute_to_expireで指定した時間をすぎると、2番目の注文がキャンセルされてしまいます。
さらに、子注文の情報は以下のようになります。若干sendchildorderの引数名と異なります。
order1 = { "product_code": "FX_BTC_JPY", "condition_type": "LIMIT", "side": "BUY", "price": 1000000, "size": 0.1 }
最後に、注文する際のコードは以下のようになります。
sendparentorder( order_method = "IFDOCO", minute_to_expire = 10000, time_in_force = "GTC", parameters = [ { #IFD:指値で買い注文、約定したらOCO注文 "product_code": "FX_BTC_JPY", "condition_type": "LIMIT", "side": "BUY", "price": 1000000, "size": 0.1 },{ #OCO①:指値で売り注文(利確) "product_code": "FX_BTC_JPY", "condition_type": "LIMIT", "side": "SELL", "price": 1001000, "size": 0.1 },{ #OCO②ストップ注文、トリガー価格を下回ったら成行で注文(損切) "product_code": "FX_BTC_JPY", "condition_type": "STOP", "side": "SELL", "trigger_price": 999000, "size": 0.1 } ] )
戻り値には
parent_order_acceptance_idが返ってきます。
注文状況を確認する
親注文の状況を確認したい場合は、getparentorders()を使います。
getparentorders( product_code='FX_BTC_JPY' ) >>[{ #(ログをとっていなかったので以下の注文結果は公式から拝借。) "id": 138398, "parent_order_id": "JCO20150707-084555-022523", "product_code": "BTC_JPY", "side": "BUY", "parent_order_type": "STOP", "price": 30000, "average_price": 30000, "size": 0.1, "parent_order_state": "COMPLETED", "expire_date": "2015-07-14T07:25:52", "parent_order_date": "2015-07-07T08:45:53", "parent_order_acceptance_id": "JRF20150707-084552-031927", "outstanding_size": 0, "cancel_size": 0, "executed_size": 0.1, "total_commission": 0 } ...... ]
parent_order_stateは、親注文自体の注文状況です。
例えば、注文種別がIFDやIFDOCOの場合、
最初の注文はCOMPLETEしているが、次の注文はACTIVE…といった状況があります。
この場合は、outstanding_sizeで見分ける必要があります。
outstanding_sizeが0より大きければ、未約定の注文がある=2番目の注文が未約定と判断します。
子注文ごとの取得価格、取引量を確認する
先程のgetparentorders()で注文状況がわかりました。
"price"という項目がありますが、これは公式によると「参考価格」だそうです。
IFDやIFDOCOのように2つの注文が約定する場合、各子注文の取得価格が知りたいわけですが、getparentorders()の結果からでは知ることができません。
各子注文のpriceとsizeは、getchildordersの引数にparent_order_idをいれることで該当する子注文の約定情報を取得することができます。
getchildorders( product_code = "FX_BTC_JPY", parent_order_id = xxxxxxxxx ) >>[{ "id" : 182386109, #エントリー時の注文 "child_order_id" : "JFX20171219-175406-686140F", "product_code" : "FX_BTC_JPY", "side" : "BUY", "child_order_type" : "LIMIT", "price" : 2519026.0, "average_price" : 2519026.0, "size" : 0.03, "child_order_state" : "COMPLETED", "expire_date" : "2017-12-22T12:34:06", "child_order_date" : "2017-12-19T17:54:06", "child_order_acceptance_id" : "JRF20171219-175406-581421", "outstanding_size" : 0.0, "cancel_size" : 0.0, "executed_size" : 0.03, "total_commission" : 0.0 },{ "id" : 182386274, #クローズ時の注文 "child_order_id" : "JFX20171219-175409-686437F", "product_code" : "FX_BTC_JPY", "side" : "SELL", "child_order_type" : "LIMIT", "price" : 2521016.0, "average_price" : 2521016.0, "size" : 0.03, "child_order_state" : "COMPLETED", "expire_date" : "2017-12-22T12:34:06", "child_order_date" : "2017-12-19T17:54:10", "child_order_acceptance_id" : "JRF20171219-175406-581434", "outstanding_size" : 0.0, "cancel_size" : 0.0, "executed_size" : 0.03, "total_commission" : 0.0 }]
親注文で約定した情報の取得方法がわからなかった(get_parentordersには約定情報が入っていない)が、どうやらget_childordersの引数にparent_order_idを入れると、OPEN-CLOSEの約定情報が取得できるようだ!これでポジションごとの損益を残せるぞ!
— たら (@tarax86) 2017年12月17日
追記
注文種別がSIMPLEの場合、エラーがかえってきます。
パラメータは正しいと思うのですが…
子注文で注文しろということでしょうか…
約定情報を取得・分析してみる【bitFlyer Real Time APIの時系列分析】
はじめに
bitFlyerのReal Time APIでは、
①Ticker(周期的な情報) 、②Executions(約定情報) 、③Board(板情報)が入手できます。前回の記事では、①Tickerを使った時系列分析を行いました(集計・可視化しただけですが…)
①Tickerは、現在のレートを知る…といった基本的な情報を知ることができますが、今回はもっと自動売買や予測に使えそうな情報を求めて、②Executionsのデータ収集・集計・可視化を行いたいと思います。③Boardは次回。
②Executionsと③Boardは、板の流動性を知ることができる重要な情報だと考えています。予測や自動売買で使うならこちらのデータが重要になってくると思います。
分析方法 Executions(約定)とは?
Executionsは、以下のPubNubチャンネルから取得できます。
PubNubからのデータ取得について:
BitCoinのリアルタイムデータを取得する。 - 仮想通貨の週末自由研究
板 | PubNub チャンネル名 |
BTC/JPY 板(現物) | lightning_executions_BTC_JPY |
BTC/JPY FX 板 | lightning_executions_FX_BTC_JPY |
ETH/BTC 板 | lightning_executions_ETH_BTC |
今回分析するのは、BTC/JPY 板(現物)です。全部見るのは疲れます…
データ構造は以下の通りです。約定が発生するたびに配信される…そうです。
[ { "id": 39361, "side": "SELL", "price": 35100, "size": 0.01, "exec_date": "2015-07-07T10:44:33.547", "buy_child_order_acceptance_id": "JRF20150707-014356-184990", "sell_child_order_acceptance_id": "JRF20150707-104433-186048" } ]
1つのメッセージ内に、上記の構造をしたdictionaryが配列に複数入っている状態で返ってきます。
ところで、この"side"という属性は、約定した際の注文の売買種別だそうです。
side
: この約定を発生させた注文(テイカー)の売買種別です。 板寄せによって約定した場合等、空文字列になることがあります。
引用元:ビットコイン取引所【bitFlyer Lightning】
テイカー、つまり売りの成行き注文が成立した場合、この約定はside = Sellとなります。このとき、板に並んでいたASKの量が減ります。
逆は、Buyということになります。板に並んでいたBIDの量が減ります。
私はこの売買種別の取引量が、買いや売りの勢い(=レートの変動)と関連しているのではないかと思っています。
では、分析結果を以下に示します。
分析結果 2017/11/27(月) ~ 2017/12/01(金)
2017/11/27
BTC_JPYの約定情報を、売買種別に10分間隔で集計しました。
10分間の約定量を積み上げグラフで表しています(目盛りは左軸)
また、10分間のレートの平均値を折れ線グラフで表しています(目盛りは右軸)
11/27の一日の変動を下図に示します。
前の日が日曜日ということもあるからでしょうか?深夜の取引が活発です。
また、レートの変動が大きいときほど、取引量も増大しているようにみえます(9:30 ~と18:00~)
9:10、9:20、9:30台について、取引量は少ないですが、買いの注文の割合が多いように見えます。そして、その後レートは大きく上昇しています。なにか予測のヒントになりそうです…
また、レートが下がっているときは、売りの注文が多いようです。まぁなんとなく可視化しなくてもわかりますが…
2017/11/28
28日は、売りの注文が多い割に、レートは上昇しているという腹落ちしない結果となりました。ここは板情報を見てみないとわからないです。
また、10:30ごろの異様な量の売り注文はなんでしょうか。集計ミスということはないと思いますが…原因不明です。
2017/11/29
29日。うん、レート上昇時は買い注文が多く、下降時は売り注文が多い。まぁ妥当ではないでしょうか…(適当)
2017/11/30
11/30。この日は、130万円台から100万円台まで急降下した日でした。(Y軸の範囲が統一されてなくてわかりにくいですが…)
4:00台に売り注文が殺到しています…ひどい相場ですね。
2017/12/01
約定の売買種別割合の時系列変動
2017/12/01
約定量の売買種別を割合にしてみました。左軸が0 - 100%となっています。
約定量の売買種別を割合で示してみた。この割合の変動をうまく平滑化して傾向をつかむことができたら、ある程度予測ができるんじゃないかなぁ。もちろん単純に相関があるってわけではないけど。 pic.twitter.com/lrHwtlPZLe
— たら (@tarax86) 2017年12月2日
暴落した日の割合。全体的に売りの注文割合が多め。4時台の暴落時に売り注文が殺到するが、その後の買い注文が多い。こういう傾向をつかめば予測できるんじゃないかなぁと思っています。
まとめ
bitFlyerのReal Time API の Executionを用いて今週のBTC_JPYを分析しました。
買い注文が多ければレートが上昇し、売り注文が多ければレートが下降する場合があることがわかりました。(もちろん、そうでない場合もままある。)
予測や自動売買で使えそうな指標であることがわかりました。
次回は、板情報を分析しますが、それと組み合わせて使うとよりレートの傾向がわかるのでは??とわくわくしています。
板を流動させるテイカー(ほぼ成行注文)、板を厚くするメイカー(指値注文)。単に売りか買いかしか考えてなかったが、ゲームみたいで楽しい。
— たら (@tarax86) 2017年11月29日
BTC_JPYのTicker情報を集計・可視化してみた【bitFlyer Realtime APIの時系列分析】
はじめに
twitter界隈でpythonによる仮想通貨BOTなるものをつくったよーというツイートが流れる度に、私も早く作りたい…と焦りを募らせています。
BOTの開発自体は比較的難しくないと思いますが、儲かるBOTをつくるためにはデータの特性をよく理解しないと、やみくもに作っても精度が低かったりとよくわからないものができあがってしまうため(体験談)、辛抱強くデータを舐め回した後にしっかりとしたアルゴリズムを作りたいと思う次第です。
さて、ようやく一週間分のデータを収集することができたので、基本的な統計解析を行いたいと思いますー。
分析対象
対象チャンネル:
以下のRealtime APIから取得できる情報をmongodbに溜め込んでいます。
BitCoinのリアルタイムデータを取得する。 - 仮想通貨の週末自由研究
・'lightning_ticker_BTC_JPY' : ビットコイン取引所の相場情報
・'lightning_ticker_FX_BTC_JPY' : Lightning Web(レバレッジ取引できるほうのBTC相場)
・'lightning_ticker_ETH_BTC' : Lightning Web上のイーサ?ビットコインで買えるのか。買ったことないのでよくわからないが参考程度に。
分析期間:
2017年11月19日(日)13:00ごろ ~ 2017年11月25日13:00ごろ(土)
分析項目
①ltp(最終取引価格)の1時間ごとの平均値、標準偏差をみます。どの時間帯が激しく変動しているのか、穏やかなのかをざっくりと掴みます。
tickerで取得できる項目は過去記事へ
bitFlyerのRealtime APIで取得したデータを分析してみる - 仮想通貨の週末自由研究
②volume(取引量)の1時間ごとの平均値、標準偏差を出力し、時間帯別取引量の変動をみます。しかし、この取引量は売りなのか買いなのか種類がわからないので、ざっくりとみるだけにします。
(かなり大雑把な)分析方法
1.mongodbから取得したデータをpandasでDataFrame化
df = pandas.DataFrame(data)
2.日付と時刻(1時間間隔)でグループ化
df.groupby*1
3.2.のdescribe()で一時間ごとの平均値と標準偏差を取得
df.groupby*2.describe()
4.3.の結果をプロット
df.groupby*3.describe().plot()
分析結果
①ltp(最終取引価格)の1時間ごとの平均値、標準偏差
サンプルデータ
まずは、サンプルデータの集計結果を下表に示します。
BTC_JPY | FX_BTC_JPY | ETH_BTC | |
1時間平均取得データ数 | 49633 | 69291 | 3620 |
11/19 13:00 - 11/25 13:00 までの総取得データ数 |
7097535 | 9908595 | 517678 |
1時間の平均サンプル数はBTC_JPYは50K、FXは70K、ETH_BTCは3Kとなっていました。ビットコインとイーサの更新頻度の差がすごい...。一週間の合計サンプル数はAPIから受け取ったデータをそのまま保存するとFX_BTC_JPYで10Mとなります!そんなにいらない...分析するときにメモリが足りない...今後どう扱うか考える必要あり。
ltp(最終取引価格)の1時間平均値の推移
以下に各レートの1時間平均値の推移を示します。
今週はイーサがかなり値上がりしているようです。また、BTC_JPYとFX_BTC_JPYの変動は1時間単位でみるとほぼ同じようにみえます。
ltp(最終取引価格)の1時間標準偏差の推移
以下に1時間ごとの標準偏差の推移を示します。
BTC_JPYと_FX_BTC_JPYを比べると変動自体は似ていますが、変動の大きさでいえばFX_BTC JPYが大きい、つまり心臓に悪い相場ということになります。まぁBTC_JPYもたいがいですが...
イーサの変動はよくわからないのでスルーします。
ltp(最終取引価格)の11/19-25の時間帯別標準偏差
ここで今回一番知りたかったこと、時間帯で変動は異なるのかどうか。
日本円での取引だからなのか、ビットコインの取引が日本で活発だからかなのかわからないですが、午前5時頃がもっとも変動が少なく、昼~夕方・夜中に変動が大きくなっています。日本人の取引が活発になりそうな時間帯に変動が大きくなっているので、なんとなく納得できる形となっています。イーサのほうはわかりません。ここで検定でもして有意であることを証明するべきですが、趣味でやっているので、「なんとなく違いがありそうだ」でとどめます。
②volume(取引量)
すみません。volumeをみてましたが特に変動はありませんでした。というのも24時間取引量なので、差分をとって時間帯別に合計したりと加工が必要のようです。あいまいな指標をこねくり回すより、Tickerとは別チャンネルのExecution(約定情報)のsize(取引量)を集計したほうがbuy,sell別に変動を見ることができたりとメリットがあるので、次回集計・分析します。
最後に
mongodbとpandasで、あっという間に集計、可視化ができて大変捗りますが、
いかんせんメモリが足りない。
メモリが128GBくらい欲しいです。16GBだとかなり厳しい…
もしくはメモリ節約できる技術力が欲しい…
tipmonaを利用してモナゲしてみる。
モナコインには、他の仮想通貨にはない独自の機能があります。
今回は、tipmonaを体験してみたいと思います。
tipmonaとは?仕組みについて
tipmonaはtwitter上で、モナコインの授受ができるサービスです。
twitterアカウントさえあれば、@tipmona tip --- と呟けば、モナコインを別のtwitterアカウントに送ることができます。
使い方は、monappy.jpにて紹介されています。
tipmonaの仕組みとしては、
・「モナコインちゃんbot」がtwitterアカウントに紐づけされたモナコイン口座(のようなもの)を自動的に作成、管理してくれる。
・twitter上で@tipmona ---と呟けば「モナコインちゃんbot」が自分の口座から送金してくれる。
・自分が呟かなくても、相手からモナコインを渡してくれば自動的に口座ができる。
(某大統領にモナコインを投げつけることができるわけです。)
tipmonaを利用するためには、自分のウォレットからの入出金が必要。
ここで、仮想通貨歴の浅い私は、以下のような疑問が湧いてきました。
つぶやくだけで、簡単に相手にモナコインが送れるわけですが、
・そもそも相手に送るためのモナコインはどうやって準備すればいいの?
・もらったモナコインはどうやって使えばいいの?
もちろん、送るためのモナコインは最初は0MONAです。チャージする必要があります。また、tipmonaでもらったモナコインを使うためには、自分のウォレットにモナコインを移す必要があります。下図のような感じです。
twitterアカウント以外登録不要なのは確かなのですが、前提条件としてウォレットは必要です。(仮想通貨の入金・出金自体したことがなかったので、tipmonaと自分のウォレットの関係を理解するのに時間がかかりました…)
① モナコインちゃんbotにモナコインを入金する。
tipmonaを使って、誰かにモナコインをあげたいなら、まずはモナコインが必要です。
その場合は、自分のモナコインウォレットから、tipmonaにチャージしなければいけません。(さらに言うと、モナコインはマイニングでゲットするか、仮想通貨取引所から購入しないといけない。)
「@tipmona deposit」とツイートすると、以下のような入金用アドレスがリプライで返ってきます。
ここに送金すれば、自分のtwitterアカウントに紐づけされたtipmona上の口座(のようなもの)にチャージされます。(送金してから使えるようになるまで数十分かかりました。)
ちなみに、「@tipmono balance」で残高を教えてくれます。
② tipmona上のモナコインを自分のウォレットに送金する。
tipmona上のモナコインを使いたい場合は、以下のように「@tipmona withdraw 金額 アドレス」と呟くことで、自分のウォレットに送金することができます。
@noteは、フォロワーさんのタイムラインに呟きを表示させないようにしています。
よくよく考えたらtwitter上でまとまった金額を受け取るようなことはそうそうないだろうから、withdrawはあまり使わないだろうな…
ちなみに、
開発者さんに寄付したらモナコインちゃんからいいねもらえました。
わーい、たーのしー。
Bitflyer RealTime API の更新頻度はどの程度か?
RealTime API (Ticker)の更新頻度はどの程度か?
ざっと調べてみました。
今回の集計データは、4時間分のBTC_JPYです。
PubNubのチャンネル「lightning_ticker_BTC_JPY」から取得しました。
下表に、1時間ごとのデータ数を示します。
Ticker |
時間帯 | 取得データ数 |
2017/11/19 | 14:00:00 | 50636 |
2017/11/19 | 15:00:00 | 51308 |
2017/11/19 | 16:00:00 | 55616 |
2017/11/19 | 17:00:00 | 56162 |
取得データ数は50000 / 1時間ほどです。
更新間隔の統計値です。
(※更新間隔[ms] = データ取得時のタイムスタンプ - ひとつまえのデータのタイムスタンプ)
[ms] | |
count | 229534 |
mean | 67 |
std | 76 |
min | 0 |
25% | 31 |
50% | 47 |
75% | 78 |
max | 5478 |
平均67ミリ秒間隔で更新されています。
最大5秒となっています。なぜ5秒も空いているのかを調べるのも楽しそうですがまた次回にて。
次に、更新頻度のヒストグラムを作成しました。
だいたい200ミリ秒以内に更新されています。
bitFlyerのRealtime APIで取得したデータを分析してみる
bitFlyerのRealtime API
bitFlyerのRealtime APIでBitCoinの情報を取得して、mongoDBに溜め込んでいます。溜め込んではいるものの、中身をあまり把握していないため、予測をする前にいろいろと分析してみようと思います。
「lightning_ticker_BTC_JPY」チャンネルの取得
Realtime APIで取得できる種類は、板情報、約定情報、tickerです。今回はtickerチェンネルを取得してみます。以下のようなデータが取得できます。
"best_ask" : 631549.0,
"best_ask_size" : 0.23970069,
"best_bid" : 631200.0,
"best_bid_size" : 1.49159631,
"instrument" : "BTC_JPY",
"ltp" : 631200.0,
"product_code" : "BTC_JPY",
"tick_id" : 16987632,
"timestamp" : "2017-10-14T09:07:59.3941616Z",
"timetoken" : NumberLong(15079720792143573),
"total_ask_depth" : 1516.36024802,
"total_bid_depth" : 4735.91225534,
"volume" : 23453.91494245,
"volume_by_product" : 23453.91494245,
取得方法は過去記事へ。
取得結果
集計するデータは、BTC_JPYです。pandasで1時間ごとの統計値を算出しました。pubnub取得プログラムが途中で終了してしまうため、まとまったデータが取得できていないですが、まぁ下表の時間帯はしっかり取れているようです。
年月 | 時間 | 取得サンプル数 | 1時間平均値 | 1時間標準偏差 |
2017/10/14 | 14:00:00 | 7873 | - | - |
2017/10/14 | 15:00:00 | 40545 | 639836 | 1047 |
2017/10/14 | 16:00:00 | 37343 | 640399 | 1043 |
2017/10/14 | 17:00:00 | 39525 | 641470 | 629 |
2017/10/14 | 18:00:00 | 38188 | 637724 | 2664 |
2017/10/14 | 19:00:00 | 30247 | 636109 | 1447 |
2017/10/14 | 20:00:00 | 37034 | 637918 | 893 |
2017/10/14 | 21:00:00 | 36255 | 638868 | 1562 |
2017/10/14 | 22:00:00 | 33516 | 641497 | 816 |
2017/10/14 | 23:00:00 | 35479 | 645063 | 2594 |
2017/10/15 | 0:00:00 | 37198 | 648592 | 1112 |
2017/10/15 | 1:00:00 | 37554 | 647967 | 919 |
2017/10/15 | 2:00:00 | 36314 | 648938 | 523 |
2017/10/15 | 3:00:00 | 21677 | - | - |
1時間で3万~4万のデータが返ってくるようです。常に一定間隔ではないようです。1分間に500回データを取得していることになります。少し過剰かも。
2017年10月14日のBTC_JPYは64万円台です。現在11月で80万~75万あたりなので随分昔のように感じます。また、1時間の標準偏差は500円~2500円ほどです。1日だけではなんともいえませんが、複数の日を時間帯別でみてみると傾向があるかもしれません。(そのためには、取得プログラムが途中終了しないようにしないと…)