CoinCheckで取引を始める前から凍結された話 (追記:2017/12/28)

bitFlyerだけでは足りぬ

仮想通貨がバブルのように高騰してるということで、いっちょ参戦してみようとbitFlyerで取引をしていたのだが、いかんせん対応しているアルトコインの種類が少なくて手を出したいコインを取り扱っていない問題の直面

ならばと調べてみたら、国内の仮想通貨取引所ではCoinCheckというところが1番アルトコインを扱っているらしい。

CoinCheckに申し込み

体感として仮想通貨はいつ何時上がるか予測しにくいので、時間との勝負だなと思い、早急にCoinCheckのアプリをDLして、会員登録、本人確認書類の提出を行なった。

本人確認書類の提出には、下記の3つをWeb上から提出する必要がある。

1. 身分証を持っている自撮り
2. 身分証の表面
3. 身分証の裏面

昼休憩中にパパーッと提出は完了した。あとは、承認待ちである。承認には1〜2日かかると記載があったので、とりあえず待つのみ。

突然の死！(凍結

本人確認書類を提出した翌日、CoinCheckのアプリを何気なく起動したら、突然「アカウントが凍結されたため、ご使用のアカウントでのログインは出来なくなりました。」のような表示が出た。

何も凍結される身に覚えがないので、メールを確認したところ下記メールがきていた。

なんの前触れもなく凍結されてご理解お願いされても無理がある。

さすがに納得いかなかったが、「詳細に関しては開示しておりません」と書いているあたり、何を聞いても詳細は開示できませんのテンプレメールが返ってくるのが目に見えている。

ただ納得いかない以上はダメ元でこのメールに返信をしてみた。以下自分の返信とそれに対する反応。

不可解すぎるCoinCheck

OK、非承認になったのはわかった。ただ、非承認になる理由が皆目検討もつかない。

ケース1 金銭面

• 過去に支払いを延滞させたことない
• 現時点でクレカを使っているので、それなりの信用はある
• 会社員として働いているので収入面も問題ない
• 同業他社のbitFlyerで取引実績もある

これらから金銭面では全く問題ないはずである。

ケース2 身分証

• 本人確認書類として免許証を使用
• 提出した画像はiPhone Xで撮影

身分証としての書類も画像の画質も問題ないはずである。

ケース3 各種重要事項

• プライバシーポリシーに同意
• 電子交付に関する同意書に同意
• 取引説明書の確認
• 利用規約に同意
• Payment利用規約に同意
• 加盟店規約に同意

ここらへんチェック項目多く、正直一切読まずに同意にチェックをつけた。
非承認の理由があるとしたらここかもしれないが、読まない人が多いこの手のもので一々落としていたら、もっと凍結されたという人が居てもよさそうなのに見当たらない。なので、違うかな？と思っている。(今後コインチェックを利用する予定の人は念のためちゃんと読むことを推奨します。)

ネットで自分と同じように本人確認書類の承認で凍結された人がいないか確認したところいた。

tenmusu.biz

ただ、この人は本人確認のところで不備があり2回非承認の後、3回目の非承認で凍結されている。

私の場合、何もなく1発凍結されている。マジで意味わからない。審査が厳しくなって1発非承認で凍結とかにでも変えたのだろうか？

そもそも非承認になった時点でアカウントを凍結させる意味も不明。そして承認の詳細開示はしていないと予防線を貼っているあたり、完全に闇しかない。

最終的結論

CoinCheck自体は国内でビットコインの取引No.1の仮想通貨最大手ではあるが、手数料も国内No.1の高さだのサポートが悪いだの色々と調べると評判もよろしくなかった。個人的主観で言わせてもらうと、今回の凍結で殿様商売って感じの印象しかなく最悪。

色々内部事情詳しい人から話も聞こうかと思ってたが、CoinCheckで取引できるようになっても、もう使いたいと思えなかったので時間の無駄だと思い止めた。

今回の救いは、まだ入金をしていなかった点につきる。入金していて凍結された場合、全額没収されるので、CoinCheckに搾取どころかカツアゲ状態になっていたかもしれない。

"Coin Check 凍結"で調べると、前触れもなく凍結された人がチラホラいるらしく、結構信用ならない取引所だとわかる。既に利用している人は気をつけた方がいいかもしれない。

コメント頂いたのでそれに対する考察(追記: 2017/12/28)

北の人なの？さんからのコメント

在日北朝鮮人はダメらしいですよ CCはテロ支援しないしっかりした企業ということですね

少なくとも祖父母両親含め日本人ですし、姓も名もTop10に入るくらいのありきたりなもの、さらには日本国籍でパスポートも取得しているので在日ではないと思います。

昔、朝鮮顔だねって誰かに言われたことはあるので、見た目そう見える部分はあるかもしれません。そうなると、免許証の写真だけで朝鮮人判定しており、CoinCheckは真っ当に調査をしていない杜撰な会社ということになると思います。

国内No.1取引量を謳う会社がそんな杜撰じゃないと思いますので、この線はないでしょう。

---

名無しさんからのコメント

利用規約から登録拒否の要件は次の通りになります。

(1) 当社に提供された登録情報の全部又は一部につき虚偽、誤記又は記載漏れがあった場合
(2) 未成年者、成年被後見人、被保佐人又は被補助人のいずれかであり、法定代理人、後見人、保佐 人又は補助人の同意等を得ていなかった場合
(3) 反社会的勢力等（暴力団、暴力団員、右翼団体、反社会的勢力、その他これに準ずる者を意味し ます。以下同じ。）である、又は資金提供その他を通じて反社会的勢力等の維持、運営若しくは経営 に協力若しくは関与する等反社会的勢力等との何らかの交流若しくは関与を行っていると当社が 判断した場合
(4) 他の仮想通貨交換業者等の役職員である場合（当社が認めた場合を除きます。）
(5) 仮想通貨交換業を営んでいる又は営む予定の法人である場合（当社が認めた場合を除きます。）
(6) その他、当社が登録を適当でないと判断した場合

具体的にはこんなのが怪しいと思います。

・他取引所の関係者と思われている
・コインチェックの口座開設のアフィをスパムや悪用していた
・コインチェックが収集した反社会的勢力のリストと一致した
・または同姓同名で年が近い反社勢力がリストに載っていた
・同姓同名の人が逮捕されている

生年月日まで蓄積した反社情報を大量に持っているのは警察くらいのはずなので 新聞発表などの生年月日が不明なリストに基づいて拒否（同姓同名で年齢が同じだから念の為拒否）されていたのなら、いい迷惑ですね

具体例まで出していただきありがとうございます。

• 他取引所の関係者と思われている
  -> 私自身ほか取引所の関係者ではないですが、関係者と思われる要素があるとしたら、TwitterでbitFlyerのことを呟いていることですかね…他思い当たる節はないですし、確証得難いので難しいところです。

• コインチェックの口座開設のアフィをスパムや悪用していた
  -> コインチェックのアフィがあること自体知りませんでした。なので、この線はないでしょう。

• コインチェックが収集した反社会的勢力のリストと一致した
  -> 所属している会社は一応上場会社なので、まず反社会的勢力とみなすのは無理でしょうから、この線もないですね。

• または同姓同名で年が近い反社勢力がリストに載っていた

• 同姓同名の人が逮捕されている
  -> これ、ないだろうと思って検索したら、ありきたりな名前のせいか同姓同名かつ割と年近い人が逮捕されたり反社勢力の人がいました。

どうやらこれが1番濃厚っぽいです。

マジで迷惑な話ですけど、年齢計算とか厳密に行なってチェックしていれば、別人とわかるはずなので、多忙なためか厳密なチェックは行われていない感じですね。

ざっとチェックして疑わしきは凍結せよといった感じなんでしょうか？

案外この線で1度問い合わせを行えば、凍結解除もわずかながら可能性あるかもしれません。ただ、今回の件で不審感もあるため、気が向くことあれば問い合わせようかと思っています。(今の所問い合わせる気はない。)

NSPredicateを使うと@を全角半角区別してくれない

emailのvalidationメソッド

業務中、emailのvalidationメソッドをいじることになって知った話

下記のようなコードでemailのvalidationチェックを正規表現を行なっていたのだが、 @ が全角でも true が返ってきてしまうことが発覚した。(emailの正規表現に関しては正確ではないので、そこは雰囲気で)

func isValidEmail(string: String) -> Bool {
    let emailReg = "[A-Za-z0-9._%+-]+[A-Za-z0-9]+@[A-Za-z0-9]+[A-Za-z0-9.-]+\.[A-Za-z]{2,6}"
    let predicateMail = NSPredicate(format:"SELF MATCHES %@", emailReg)
    return predicateMail.evaluate(with: string)
}

Androidでは全角半角区別されていた

同じプロジェクトのAndroid側では似た処理を行なっていたが、 @ が半角の時のみvalidとして扱われていたので、その振る舞いに疑問を覚え、Discord上のios-developers-japanコミュニティに質問投げた。

NSPredicate 使ってることもあって、iOSでもmacOSでももはや @ は全角半角区別されない仕様なのかと思っていた。

SwiftならNSRegularExpressionがある

そもそも NSPredicateを前任が使って書いていたり、自分がiOS上で正規表現を使ったことなくて知識が乏しく気づけなかったのだが、NSRegularExpressionクラスというのがあるのを知らなかった。(見たことある気もするけど、覚えてない)

んでこいつを使えば、下記のように判定はできるということを教えてもらった。

// loveeさんから提示のコード
let stringA = "123@456"
let stringB = "123＠456"

let rangeA = stringA.range(of: "@[0-9]", options: .regularExpression, range: nil, locale: nil) //.some
let rangeB = stringB.range(of: "@[0-9]", options: .regularExpression, range: nil, locale: nil) //nil

// omochimetaruさんから提示のコード
func isValidEmailFormat2(string: String) -> Bool {
    let emailReg = "[a-zA-Z0-9._%+-/:~$^()&!']+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}"
    
    // valid regexp
    let regexp = try! NSRegularExpression.init(pattern: emailReg, options: [])
    
    let nsString = string as NSString
    let matchRet = regexp.firstMatch(in: string, options: [], range: NSRange.init(location: 0, length: nsString.length))
    return matchRet != nil
}

また、NSPredicateよりNSRegularExpressionの方が標準的だろうというお話も出た。

最終的には…

NSRegularExpressionを使えば、@の全角半角の判別を正常にできるのがわかったわけだが、諸事情(時間的と引き継いだコードで振る舞いを変えづらい)により、文字列がascii文字かの判定を別途足し方式でvalidationを行なった。

var email1 = "hoge@gmail.com"
email1.canBeConverted(to: .ascii)   // true

var email2 = "hoge＠gmail.com"
email2.canBeConverted(to: .ascii)   // false

Akiba.swift 忘年会のAKIBA枠でLTしてきた

Akiba.swiftとは

岩本町にあるクラスメソッドのオフィスで開催される勉強会です。

classmethod.connpass.com

主催者は、ダンボー田中さんとloveeさん

オフィスの広さの関係もあって、最大でも20人ぐらいの小規模勉強会で、名前からも察せるようにアキバ系が好きな人が多く集まります。

AKIBA枠

今回の忘年会から思いつきで追加されたアキバ系のネタ用LT枠

過去3回くらいオーディエンス参加したり、技術系のLTやったりと参加してきたので、今回も賑やかしに参加した。

発表内容

speakerdeck.com

Akiba.swift + AKIBA枠 + 技術者 = bpS(バトルプログラマーシラセ)
このネタをやるしかない！マイナーなお気に入りアニメの布教もできる！と思いつきで登壇

2箇所くらいは動画を差し込んで 時間稼ぎ 発表に面白みを付加していたけど、Speakerdeckにあげるために静止画へと置き換わっている。

今後

色々iOSやSwiftから離れたことをプライベートでちまちまやってたけど、それが落ち着いたのもあって今週あたりからSwift触ってやりたいこと試したいことを行なっていくので、知見をまたどこかのLTでアウトプットしていきたいところ。

最低限このブログ上でまとめることはやる。

iPhone Xで出来ないこと2点

iPhone Xを触ってて気づいたこと

iPhone Xを私物として購入し、触ったりコードを動かしていて疑問に思ったことを調べた結果、以下の2つが判明 * network indicatorが表示されない * 逆さまの縦持ち(portrait upside down)が存在しない

network indicatorが表示されない

これは割とiPhone Xが発売された最初のほうから言われているので有名。iOS11.2の現在でも表示されないままである。

UIApplication.shared.isNetworlIndicatorVisible = true を行うことで、従来ではステータスバーにindicatorを表示でき、通信していることを示せていた。

また、場合によっては、通信時にこの表示を行わないとリジェクトされることもあるという話を見た。

しかし、なぜかiPhone Xでは表示されなくなっている。ステータスバー領域がフロントカメラで狭くなったことも影響しているのだろうが、2017年9月の新機種発表の時だったか忘れたが、iPhone Xのステータスバー上で新しいデザインのnetwork indicatorが表示されているシーンを見た記憶がある。

iPhone X自体前倒しでリリースされたと言われているので、今後のiOSのアップデートで表示されるようになるのでは？と思っている。

逆さまの縦持ち(portrait upside down)が存在しない

前項のnetwork indicatorが実はフロントカメラの下で見えない可能性が微レ存か？と思い、上下逆さまの画面で確認したらわかるやーんと、お試しプロジェクトを作って発覚。

iPhone XはportraitUpsideDownは機能しない。

Apple Developer Forumsでは、Appleの人曰く、"It is by design. We're getting documentation updated in a future release to reflect that." forums.developer.apple.com

つまり、デザイン上そうなってるし、ドキュメントにもそのうち反映されるとのこと。

もともと、portraitUpsideDownなんて使い道なかったし、使ってるアプリ自体極めて稀なので、なくても困らないんだろうが…

おまけの備忘録

network indicator周りで他何か使ってハックしてでも表示できないかと思い、プライベートAPIとかの表示の仕方を調べた。割と検索しにくく、記事も古いため埋もれる可能性を考慮して残しておく

memo.sugyan.com

Apple Scriptで"scrapy crawl hoge"をshellで実行しようとして躓いた話

Terminalでは上手くいくのに、AppleScriptではエラー

Terminalを起動して、 do shell script "scrapy crawl hoge" を打つと問題なく動作するのに、Apple Scriptで do shell script "scrapy crawl hoge" のようにshellを実行しようとしたところ、 sh: scrapy: command not found とエラーが出てしまった。

PATHを通しているからTerminalでは正常に動いてるみたいだし、AppleScriptではPATHとか考慮されないぽい？

commandがなきゃ大本を見つけて叩く

scrapyが見つからないなら、直接commandを叩いてやろうと which scrapy でpathを調べ /Library/Frameworks/Python.framework/Versions/2.7/bin/scrapy だと判明する。

で、
do shell script "/Library/Frameworks/Python.framework/Versions/2.7/bin/scrapy crawl hoge" を実行するのだけれど、別のエラーが出てきた。

Scrapy 1.4.0 - no active project

Unknown command: crawl

Use "scrapy" to see available commands

大きな勘違いをしていた

scrapyは見つかったけど、今度はその引数が上手く渡せていないのか？と思って、引数の渡し方を必死に調べていた。 実際は、有効なspider nameが見つからない時のエラーが出ていたわけなのだが…。

Terminalでcommandを打っている時は、現在のpathを基点に打つので無意識的にApple Scriptも出力したファイルを実行するpathを基点に動いていると勘違いをしていた。

そこで、検証として下記のように順にshellを実行したところ…

-- "--"は、Apple Scriptでコメント
log (do shell script "pwd")                -- "/"
log (do shell script "cd /Users; pwd")     -- "/Users"
log (do shell script "pwd")                -- "/"

shellの実行は必ずrootを基点として始まってて、 do shell script "" 1行毎にrootを基点とすることが判明…。

なので、scrapy project内で scrapy crawl hoge を実行しないといけないのに、ずっとrootで実行しようとしていたわけだ。そりゃエラーにもなる。

思い込み怖い

最終的に do shell script "cd /Users/(Scrapy Project Path)/; /Library/Frameworks/Python.framework/Versions/2.7/bin/scrapy crawl hoge"

のように1行でpath移動とscrapyのcommandを書くことで正常にshell scriptが動くApple Scriptを作成できた。

もっと綺麗なやりかたもあるのかもしれないが、Apple Scriptは独特すぎて学習するのも面倒なので、必要ない限りは今回のようなやり方でいいかなと思ってる。