トップ «前の日記(2013-05-13) 最新 次の日記(2013-05-17)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2013-05-14

_ arm の float

浮動少数の ABI がいろいろある。

$ cat fadd.c
float fadd(float x, float y) {
  return x + y;
}

soft だと関数呼び出しになる。引数は r0, r1, ... なんかの汎用レジスタを使うぽい。

00000000 <fadd>:
   0:   b508            push    {r3, lr}
   2:   f7ff fffe       bl      0 <__aeabi_fadd>
   6:   bd08            pop     {r3, pc}

softfp だと浮動少数命令を使う。でも引数は r0, r1, ... のまんま。 soft のやつと互いに呼んだりできるわけだね。

00000000 <fadd>:
   0:   ee07 0a10       vmov    s14, r0
   4:   ee07 1a90       vmov    s15, r1
   8:   ee37 7a27       vadd.f32        s14, s14, s15
   c:   ee17 0a10       vmov    r0, s14
  10:   4770            bx      lr
  12:   bf00            nop

hard だと calling convention が変わって s0, s1, ... が使われる。

00000000 <fadd>:
   0:   ee30 0a20       vadd.f32        s0, s0, s1
   4:   4770            bx      lr
   6:   bf00            nop

readelf して出てくる、

 Tag_ABI_VFP_args: VFP registers

ていうのがこっちの calling convention 使ってますよ、って目印らしい。

(15:26)

_ ということを前提に arm-*-tcc

arm-eabihf-tcc は hard だと思うけどビルドされてないから確認できない。

arm-eabi-tcc と arm-vfp-tcc は今回のファイルから出力されてるバイナリから見分けがつかないけど、コード見る感じ vfp のほうがレジスタ数が多いとか、まぁリッチなんだとおもう。

arm-fpa*-tcc は古いものらしい。

長年のどうでもいい謎だった arm-*-tcc がなんでこんなたくさんできるのか問題が、少しだけマシな理解になった。

しかし、実は tcc for arm って実はコレ真面目に使ってるんじゃ…

(15:43)

_ bitcoin

面白いて話なので論文を斜め読み。

http://bitcoin.org/bitcoin.pdf

ざっと概要を聞いた感じでは、採掘の方はうまい仕組みだな、と思ったものの、多分できそうだなーと思った。一番疑問だったのは新規参入者が現在の状態をどうやって知るかっていうのとか、取引のチェックとかどうすんの、ってことだった。これは採掘する時に新しい状態を作る人が今までのトランザクションログをハッシュにつっこむ感じでできてるらしい。採掘用とトランザクション用でデータは分けて持つイメージだったんだけど、それを混ぜるってのはかっこいいというか、よくできてるなーと感心した。なんていうか一人ひとりの質問にいちいち答えるんじゃなくて、一気に答えるってのは、いいと思う。

んでいくつか疑問が。

まずスケールするの? てこと。

https://en.bitcoin.it/wiki/Scalability

ここに色々書いてある。 disk がちょっと危なっかしいのと、論文にあったツリーの枝狩りってやつをなんでやっていいのかよくわかってないけど、なんとなくそれっぽいことが書いてある気がする。ただ、僕が気になるのは latency で、本当にアホほど使われるようになってからも10分後のブロックにちゃんとverifyされた結果が入ってくるか、っていうと、本当にうまくいくのかピンときてない。

次に DOS されるときつくね、っていう。すごい細かいトランザクションを無駄に大量に流されるときつくね?

verify するだけの子とかが参加してる前提ぽいけど、現状彼らのインセンティブはなんなんだろうか。採掘ノードはタイムスタンプサーバを機能させるインセンティブはおおいにあるわけだけど、別にトランザクションの verify を手伝う理由はないと思う。

SHA256 が死なない前提な気がするけど、大幅に有効ビットとか減ると大変なことになったりしないかな。まあなんかソフトのアップデートとかやってるぽいから、何とかならんこともないのかなぁとか思う。

マシンたくさん持ってるアタッカーも、うまくいっても自分の前回の取引をキャンセルするくらいのことしかできないから、それよりは採掘した方がいいってのはなんかよくできてるなぁと思うんだけど、全体の価値が高まったあとだとどうだろうかなぁと。 bitcoin を叩き潰したい国家が大量のノードを動かして全力で謎の長い歴史を捏造したりすると、もちろんそれで大儲けとかはできないだろうけど、 bitcoin の機能を止めることはできる気がする。世界通貨ドルを潰すためにアメリカを戦争で叩き潰すよりは、はるかに敷居が低いと思うんだけど。

あと、この程度複雑なソフトって、バグとかちょうこわいんですが。 buffer overflow させて verification 通す! とか。

あと初期ノードは IRC からとってくるとか。最新のプロトコルが最古のプロトコルに依存するなんてかっこいい…

(17:07)

_ ついでに

買いたいかどうかを少し考えてみる。最終的な流通量は2100万BTCらしい。今は1BTC12000円くらい。今の価値のまんまBTCが採掘終了を迎えると2.5兆円。うーんそんな市場規模になるもんなのかなぁ。んで、100倍とかになるとうれしいわけだけど、なるとすると250兆。あんま現実的じゃない気がする。

この計算が適切な計算なのかは知らない。マネーゲーム的な理由ですごい増えるとかはありえるのかなぁ。よくわからない

(17:22)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2013年
5月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
1.shinh(2013-05-14 13:56) 2.いわさき(2013-05-14 02:15) 3.Egtra(2013-05-13 22:55)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h