bovine氏の発表の大意：「OGR24と平行して、OGR25の配布も始めます。参加者の皆さんは、（すでにOGR24が動いているなら）特に何もしなくてよいです。OGR24はまだまだ検証中なので、お手元に受信したOGR24のスタブを無理やり削除する必要もないです。ただたんに、25ノードのスタブが来るのを待っていればよいです」ということのようです。詳しくは氏のFingerを。
すぐに発表しないのは、なんとかネコババする方法はないかな、と考えているから（＜ばかもの！）ではなくて、単に、もったいぶってじらしているのです(^^)
0:123456789012とか、1:6543210 などのように、x:y という形になっています。この x に2の32乗を掛けたもの ＋ y がそのスタブのノード数になります。
熊谷博士には、心からお礼を申し上げます。本当にありがとうございました。このお礼は、次回のローラシリーズで！（＜お礼になるのか？）
なんと、この２チームに追いつくと、一気に国内20位台ということになります。
たったいま、主力から数台をＯＧＲに回したんだけど、早速にでもＲＣ５に戻したほうが良いかなぁ(^^)
クライアントをダウンロードしてアップデートするのだって、数分は掛かるわけで、何かのついでか、時間のあるときにでもやってくださればＯＫです。もちろん、そのときに分からないことなどあれば、僕や他のメンバーが、お手伝いしますので、ご安心ください！（といいつつ、曖昧な説明をして、他のチームの方から教えていただくこともままありますが(^^)）
・・・って、タイムスタンプを見たら、なんと７月９日でした。見落としていてごめんなさい！
こういう忙しいときに、狙ったようにＯＧＲ再開ですね(^^)
ということで、みなさん。ぜひぜひデカスタ・チビスタにご参加くださいませ！
ところがところが、踊る暗号解読班もかなり健闘しました。思ったほどには引き離されませんでしたね。まだまだぜんぜんランデブー状態です。それもこれも、メンバーの皆さんがいつもより余計に回す作戦に協力してくださったからですね(^^)
BangDollさんたちのブロックがまだ計上されてませんからね。明日以降、どこまできのこ雲が膨れ上がるか、恐ろしくもあり、楽しくもあり(^^)
いまのところ、まだまだ余裕で相手をしていられますが、それもいつまでかなぁ。楽しみですね(^^)
I just thought I'd let everyone know that we're currently experimenting with enforcing a minimum block-size for RC5.
現在、RC5の最小ブロックサイズを制限する実験をしてること、皆さんにお知らせしとこうかな、と思いまして。
This means that even if you have your clients configured to request 2^28 blocks, you will likely get a larger sized block instead.
つまり、クライアントの設定で、2^28 サイズのブロックを要求するように設定しておいても、もっと大きいブロックが受信されることになるかもよ、ってことです。
As we are being faced with an ever increasing amount of network traffic caused by our phenomenal growth, we would like to explore the impact cause by allowing smaller sized blocks to be explicitly requested by clients.
我々は、ものすごい勢いで大きくなってまして、そのせいで日々増え続けるネットワーク通信の量の増加に直面してます。で、それが、クライアント側でわざわざ小さいサイズのブロックを要求できるようにしているせいじゃないか、ということを調べておきたいんです。
So far, we have found that an extraordinary number of people configure their clients to request small 2^28 sized blocks, even though their processors are more than adequately fast enough that packets are completed frequently enough that there is no legitimate need for those specific machines to configured to request such small blocks.
ここにきて、ちょっと尋常でないほど多くの人が、2^28という小さなサイズのブロックを受信するように設定していることが分かりました。ひっきりなしにブロックを処理するのに十分なほど早いプロセッサで、あえてこんなに小さなブロックを受信する必要はないのに、です。
Although allowing your client to process smaller blocks has the visual appearance of seeming to complete work packets more rapidly, it does place an increased burden upon the donated network resources of our servers, in addition to increasing the daily processing overhead required by our stats server. It additionally contributes towards keyspace fragmentation at a greater rate than larger blocks do.
クライアントで小さなブロックを処理させるようにしておけば、見た目上、ブロックを速く処理してるように見えますよね。でも、それって、寄付でまかなわれている我々のサーバーの負担を増加させちゃうし、おまけに、ランキングサーバの日々の処理作業も増えちゃうんです。しかも、大き目のブロックを受信する場合に比べて、残りの鍵束をもっとずっとぶつ切りにしてしまいますよね。（訳注：残りの鍵束から、ところどころ虫食いのように小さいブロックを受信してしまうと、中途半端な大きさのブロックが残ってしまう）
Therefore we'd like to request that everyone evaluate their client configurations and check whether they've configured their client to specifically request small 2^28 sized blocks and think about whether you really need to request blocks that small. If your machine completes a 2^28 sized block in less than 45 minutes, then your computer is fast enough that it really should be processing larger blocks.
そんなわけで皆さんには、クライアントの設定を確認して2^28サイズの小さいブロックを受信する設定になっていないか調べるのと、本当にそんな小さなブロックでなきゃいけないのかどうかの見直しをお願いしたいんです。お手元のマシンが2^28サイズのブロックを45分以内で処理できるとしたら、そのコンピュータは、本当にもっと大きいブロックを処理するのに十分な速さですよ。
The ability to request small blocks should really be reserved for unstable, slower machines that might have greater potential of crashing before completing an entire packet.
小さなブロックを受信する機能は、処理中のブロックを完了する前にクラッシュしかねないほど不安定な、遅いマシンだけのものにしましょうね。
Additionally, those slower machines should definitely consider enabling checkpointing, to allow blocks that are lost in the middle of processing to be resumed. Note that clients that use network shared ini's and buffers need to use distinct checkpoint files, so you should use caution if you administer machines in that manner.
それと、こういった遅いマシンでは、いっそきっぱりチェックポイントファイルを有効にすることも検討しましょうね。処理の途中でこけてしまったブロックを、そこからやり直すことができますから。あ、ネットワークでiniファイルやバッファを共有しているクライアントは、めいめい別のチェックポイントファイルを持たなきゃいけません。そういう方法でマシンを管理している人はお気をつけ下さい。
というわけで、導火線が燃え尽きる前に、少しでも遠くに行っておきましょう＞ＡＬＬ
現在、52Kブロック差です。ちーぴかさんの、溜め込み開始前のレートがおおむね50K/Day、現在は20K/Dayというところですから、途中で多少の暴発やお祝い事などがあったことを計算に入れても、1.2Mから1.5Mほどの規模の爆発になる可能性が高いです。2.0Mぐらいいくかも知れませんね。
ちょっとわくわくしませんか？(^^)
あらためて、踊る暗号解読班へようこそ！