2020-04-19

WindowsからLinuxにファイル転送する際の注意点

WindowsからLinuxサーバー上にファイル転送した際に、ちょっと面倒なことが起きたので備忘録。
間違ってたらすみません。

起きたこと

Windowsから以下のようなシェルスクリプトをLinuxサーバー上に送ったらファイル名が変なことになった。

・・・
[プログラムの実行] > result.log
・・・

WindowsとLinuxの文字コードの違い

半角の英数字を使う分には、「Shift_JIS」であろうが、「EUC-JP」や「UTF-8」であろうが、違いはない。
3つは英数字の文字コードは同じである。
しかし、改行の定義には違いがある。

Windowsでは、改行はCR+LFで定義されている。
CRとは、キャリッジリターン(Carriage Return)のこと。
カーソルを左端の位置に戻すことを意味する。
LFとは、ラインフィード(Line Feed)のこと。
カーソルを新しい行に移動することを意味する。

これに対し、Linuxでは、改行はLFで定義されている。
Linuxでは、CRは表示されない。

もしWindowsのエディタで作成した、上記のコードをLinuxにバイナリー転送した場合、
改行コードは変換されることなく、CRの文字を含んでいる。
そのため、リダイレクトにより作成されるファイルは、result.log+CRとなる。
Linux上では、CRは表示されいため、表示上はresult.logに見える。
しかし、less result.logを実行しても、ファイルを見つけることはできなくなっている。

CRがファイル名に入ることでの不具合

FFFTPなどによって、result.logのファイルを操作しようとした際、表示にはファイルが出ている。
しかし、ファイルをダウンロードなどの操作をしようとしてもエラーとなる。

ファイル名からCRを除く方法

以下のコマンドでCRがファイルの最後尾に含まれていても、見つけることができる。

ls result.log*

ファイル名を変更する。

mv result.log* result.log

・・・改行文字を直接していするにはどうすればいいんだろ？

2020-04-19

BitcoinとCorda

Bitcoin Corda blockchain

BitcoinとCordaの違いについて、備忘録。

Bitcoinの不正改ざんについて

Bitcoinは、ブロック同士が連結され、簡単には改ざんできなくなっている。
1つのブロックは、ヘッダーと大量のトランザクションによって構成される。
このヘッダーを、SHA256アルゴリズムを用いて2回ハッシュ化し、32ビットのハッシュ値を生成する。
これを、ブロックハッシュという。
このブロックハッシュは、各ブロックを識別するIDでもある。

ヘッダーは、いくつかの情報を持つ。
ブロックヘッダ
ヘッダーには、Nonceという、4バイトの自由に値を変えられるフィールド、タイムスタンプのフィールドが存在する。
これらの値を変えることで、ブロックハッシュはランダムな値をとる。
このブロックハッシュを、指定した値より小さくなるまで、計算するのがマイニングである。
この計算は、ビットコインネットワークに参加するマイナーたちが10分ぐらいで計算できる難しさになっている。
難しさは、指定する値の大きさを変更することで調整できる。
すべてのマイナーの計算機の処理能力を合わせて、やっと10分で計算できるほどの計算量が必要ということ。

ヘッダーは、前のブロックのブロックハッシュも持っている。
そのため、膨大な計算により得られたブロックハッシュにより、ブロックは一方向に連結するため、Bitcoinを不正に改ざんすることは、相当に困難である。

たとえできたとしても、今後作られるブロックに対して。
51%攻撃

Cordaについて

Bitcoinは、ビットコインネットワークの多くのノードが、すべてのブロックチェーンを保持する。
パブリックなネットワークであり、ブロックの中を誰でも見ることが可能です。

それに対しCordaは、プライベートなネットワークであり、ネットワーク外の人は、台帳の情報を見ることができない。
さらには、プライベート内の各ノードから、他のノード間のトランザクションを見ることもできなくなっている。
これは、プライベートネットワーク内のノードが、ブロック1つに対し、1つのトランザクションを保持することで実現している。
各ノードは、共通の台帳を保持していないということ。
しかし、共通の台帳を持たないということは、単一のノードだけではトランザクションが使用済みか未使用かを判断することができない。
そのためCordaは、Notaryというノードが存在する。
各ノードは、Notaryにリクエストを送り、トランザクションが未使用可どうかを確認できる。

BitcoinとCordaの違い

BitcoinとCordaの違いは、安全性の担保の仕方だと思う。

Bitcoinは、技術的に安全性を担保している。過去のブロックを改ざんするためには、とんでもない処理能力をもった計算機が発明される必要がある。
今後連結されるブロックならば、マイナーを集め、ビットコインネットワークの51%の計算処理能力を集めれば可能かもしれない。
しかし、Bitcoinを利益として得ているマイナーたちが、そのようなBitcoinの価値を下げることをするメリットはない。

Cordaは、プライベートネットワークとNotaryを第三者が運営することで安全を担保している。
Bitcoinと違い、トランザクションを含むブロックがブロックチェーンに組み込まれることを待つ必要はない。
ビジネス向けに、Bitcoinの悪い点（いい点も）削って、扱いやすくしている。

参照

Consensus
https://docs.corda.net/docs/corda-os/4.4/key-concepts-consensus.html

Notaries
https://docs.corda.net/docs/corda-os/4.4/key-concepts-notaries.html

第２回：Cordaとは何か～Cordaの特徴～
https://medium.com/corda-japan/第２回-cordaとは何か-cordaの特徴-c5d1f961e068

第３回：Cordaとは何か～Cordaの詳細～
https://medium.com/corda-japan/第３回-cordaとは何か-cordaの詳細-1b4687abf91e

Cordaの設計思想やその実装
https://medium.com/@newzhaosheng/cordaの設計思想やその実装-64c131add26

2020-04-14

ビットコインアドレスとプライバシー

Bitcoin blockchain

Bitcoinについて、備忘録。にわか知識ですので、いろいろ間違ってたらすみません。

Bitcoinのプライバシー

Bitcoinのプライバシーってどうなの？
いろいろ情報見えちゃうの？

Bitcoinのプライバシーの問題

ビットコインのトランザクションは、誰でも見ることができる。
ビットコインのブロックの情報
上記のサイトを見ると、送受信者のビットコインアドレスや金額が載っている。
ビットコインアドレスは、名義のようなもので、誰に送るかという情報です。
では、もしビットコインアドレスとそのアドレスが誰に結び付くかがわかってしまえば、その人のビットコインの送受信歴を調べられてしまうのか？
結論として、ビットコインアドレスを頻繁にトランザクションごとに変えていれば、トランザクションを追跡することはできない。

ビットコインアドレスの生成

ビットコインアドレスは、公開鍵から作成する。
そして、公開鍵は秘密鍵から作成される。

秘密鍵 ⇢ 公開鍵 ⇢ ビットコインアドレス

もちろんビットコインアドレスから公開鍵を、公開鍵から秘密鍵を逆算することはできない。

秘密鍵 ⇠✕ 公開鍵 ⇠✕ ビットコインアドレス

ビットコインアドレスを変えるためには、秘密鍵を複数持つ必要がある。
トランザクションごとにビットコインアドレスを変えるとすると、100回のトランザクションがあれば、100個の秘密鍵が必要です。
もし、どれか一つの秘密鍵でもなくせば、それに対応するトランザクションが自分のものであると証明できなくなる。

ビットコインアドレスを変えるごとに、秘密鍵を作成するのはあまりに不便であるため、多くのウォレットにはもっと簡単に秘密鍵を管理する仕組みがある。

決定性ウォレット

秘密鍵と「シード」で、無限に秘密鍵を作成できる。
そのため、秘密鍵と「シード」さえバックアップしておけば、今までに使用した秘密鍵を再生成することができる。

階層的決定性ウォレット

ルートシードさえあれば、無限に秘密鍵を作成できる。
秘密鍵から秘密鍵を作成できるため、複数のウォレットを持つ人などは、秘密鍵の使い分けもできて便利。

2020-04-06

暗号化について理解する

個人的な備忘録メモです。内容間違ってたらすみません。

WIP

暗号化って何？

例えば、「こんにちは」というテキストをAESという暗号方式で暗号化すると、「b'q+D4rchDZ2MhVdSLT47R+XVT7wVsDKhp/QaBwqd55T4='」といった意味のわからない文字列になります。これを復号化すると、「こんにちは」というテキストが得られます。例え誰かが、暗号化された情報を得られたとしても、意味のわからない文字列から、元の「こんにちは」というテキストを得るのは簡単ではありません。元に戻すには"鍵"が必要になります。

暗号化方式の種類

暗号化の方式には、大きく以下の２つがあります。

公開鍵暗号方式

公開鍵と秘密鍵のペアを用いた暗号化方式です。暗号化のアルゴリズムとして、RSAやElGamalなどがあります。使用例）SSH、ブロックチェーン

共通鍵暗号化方式

暗号化と復号化に、同じ鍵（共通鍵）を使用します。暗号化のアルゴリズムとして、AESやRC4などがあります。共通鍵暗号化方式だけでは、セキュリティ上問題があるため、公開鍵暗号方式と合わせて使用されることが多い？です。

2019-11-09

MacでScala環境の構築

必要なもの

・JDK
・sbt (scalaのビルドツール)

参照

JDKとsbtのインストールについて
https://www.scala-sbt.org/1.x/docs/ja/Installing-sbt-on-Mac.html

JDKがインストールされているかの確認

$ java -version

AdoptOpenJDKのインストール

JDK8もしくはJDK11をインストールする。
２つの違いは下記を参照。
https://qiita.com/nowokay/items/1ce24079f4daafc73b4a

↑Javaを使用する場合は、記法が変わるけど、scalaを使用する分にはどちらを入れても変わらない感じ？

下記のサイトよりJDKをインストール
https://adoptopenjdk.net

下記のように表示されるようになればOK

$ java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_232-b09)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.232-b09, mixed mode)

sbtのインストール

Homebrewを使ってインストールする。

下記のコマンドを実行

$ brew install sbt

ちゃんとインストールできたか確認

下記コマンドを実行し、sbtビルドをつくってみる。

$ mkdir sample-build
$ cd sample-build
$ touch build.sbt
$ sbt

ビルドが完了したら下記のコマンドで終了する.

sbt:sample-build> exit

下記のコマンドを実行し、src/main/scala/exampleというディレクトリを作成する。

$ mkdir -p src/main/scala/example

作成したexampleディレクトリ内に下記のファイルを作成する。
<Sample.scala>

package example

object Sample extends App {
  println("Hello")
}

コンパイルし、実行する。

$ sbt
sbt:example> compile
sbt:example> run

[info] running example.Sample
Hello

上記のようにHelloと表示されればOK

2019-03-09

配列サイズによるスタックオーバーフロー

エラーの内容

Cにおいて、double型の配列を1024*1024で確保した際、下記のエラーが出力された。

Segmentation fault: 11

原因

スタックに格納できる情報量を超えた配列を格納しようとしているため、スタックオーバーフローが起きている。

PCのスタックサイズの調べ方(Mac)

下記コマンドで調べられる。

$ ulimit -a

出力結果

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1418
virtual memory          (kbytes, -v) unlimited

8Mほどのスタックサイズに8Mの配列を格納しようとしていたことが原因だったみたい。。

解決方法

下記コマンドでスタックサイズを変更することができる。

$ ulimit -s 65532    // スタックサイズを65MBに変更

※この変更は一時的な変更

備考

今回はソースコードを変えたくなかったため、この方法で。
できれば、mallocを用いヒープ領域として動的に確保したほうがよい。

2017-12-30

boostのコンパイルが通らない

C++のライブラリのboostを使ったときにコンパイルしたらエラーが起きたのでメモです。

エラーが起きるまで

homebrewでboostをインストールし、コードを以下のようにコンパイル。

g++ -std=c++11 test.cpp

すると以下のようなエラーが発生した。

エラー

Undefined symbols for architecture x86_64:
  "boost::system::generic_category()", referenced from:
      boost::system::error_category::std_category::equivalent(int, std::__1::error_condition const&) const in test-50e82c.o
      boost::system::error_category::std_category::equivalent(std::__1::error_code const&, int) const in test-50e82c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

対処法

コンパイル時に以下のオプションをつける。

-lboost_system