0.3ほぼ完成

9 件のメッセージ サトシ・ナカモト 2010年6月22日 — 2010年6月26日

lachesis、2010年6月22日 午前6:20:02の引用次のリリースまでにlisttransactionsのRPCメソッドが完成するといいのですが。 心配しているのは、多くのプログラマーが受取支払いの確認にそれを使おうとすることだ。その方法では決して信頼性がない。list/getreceivedbyaddress/label関数が信頼性のある唯一の方法だ。

あらゆる可能な機能が完成するまで永遠にリリースを遅らせるべきではない。常にもう1つやるべきことがあるものだ。

テスト用のWindows版RC1はこちらだ: (削除済み、下記RC2を参照)

テストしてすべてが正常に見えるかどうか報告してくれる方のみダウンロードしてほしい。“c:\program files\bitcoin”内のファイルを確認してほしい。

davidonpda、2010年6月22日 午後6:23:26の引用EXCEPTION: 22DbRunRecoveryException DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery C:\Program Files\Bitcoin\bitcoin.exe in OnInit() オペレーティングシステムは何か?

通常これが発生するのは、データディレクトリが配置されるべきディレクトリが存在しない場合だ。“%appdata%“ディレクトリが存在するか確認してほしい。

0.2でもこのエラーが出るか?この点で異なるところはないので、0.2では出ず0.3で出る理由が想像しにくいのだが。

私が返信を投稿するより早く解決されたようだ。

LaszloのビルドのBerkeley DBには、私たちのものと互換性のないdatabase/log.*ファイルがあるようだ。.datファイルは問題なく、そのフォーマットは変わるべきではない。すべてのデータは.datファイルに保存されている。すべての自分のデータはwallet.datに保存されている。ブロックチェーンの再ダウンロードを待っていれば、ブロックチェーンがそれらのトランザクションが記録された地点に到達した時点で、欠けていたトランザクションと生成されたコインが表示されたはずだ。

log.0000000002を除いてディレクトリをコピーしたのは最善の解決策だ。これで問題ないはずだ。

database/log.*ファイルには一時的なデータベースデータのみが含まれている。前回Bitcoinを正常に終了した場合、つまり強制終了やクラッシュではなく正常終了した場合、database/log.*ファイルは通常安全に削除できる。これらはデータベースがトランザクションの途中でコンピュータがクラッシュしたりプログラムが強制終了やクラッシュした場合に、データを失わずに復旧するためにのみ使用される。

可能であればv0.3を使い続けてほしい、v0.2.10には戻らないでほしい。

この問題に当たった方は、database\log.000000000*ファイルをどこか別の場所に移動してほしい。(その後問題なく動作すれば、後で削除できる)

インストーラーにそれらのファイルを削除や移動させることには躊躇している。前回の実行がクラッシュや強制終了で停止した場合、それは間違った対応になるからだ。

Laszloがさらに最適化を有効にするとパフォーマンスが約20%向上することを発見したので、0.3は0.2.0より20%速くハッシュするが、彼は自分のビルドでそれを使っていたと思う。

30khash増加して合計レートはいくつになったか?(増加率を計算するために)

テスト用のLinux版RC1はこちらだ: (リンク削除済み、下記参照)

32ビットと64ビットの両方のバイナリが含まれている。

最近の変更:

build-unix.txt:

  • bitcoindのコンパイルに必要なwxBaseのビルド手順を追加。
  • libboost-devパッケージは何もインストールしなくなったため、libboost-all-devを取得する必要がある。
  • バージョン番号を更新。

makefile.unix:

  • libboostライブラリは1.40でファイル名から”-mt”を削除した。Ubuntu KarmicのようにBoost 1.38以下でコンパイルする場合は、boost_system-mtとboost_filesystem-mtに戻す必要がある。

分からない。もっとLinux経験のある方が必要なライブラリのインストール方法を知っているかもしれない。

Ubuntu 10.04でビルドした。間違いだったかもしれない。より多くの後方互換性のために、古いバージョンでビルドすべきだったかもしれない。Linuxではこれは問題なのだろうか。最新バージョンでビルドすると、古いバージョンで動作に問題が出るのだろうか?10.04でGCCの古いバージョンにダウングレードする方法はあるか?

64ビット版は32ビット版より速くないはずだが、2つのLinuxバージョンを並べて比較して確認してもらえると素晴らしい。SHA-256は32ビットアルゴリズムであり、BitcoinMinerでは64ビットはまったく使用していない。

Windows用の64ビット版は必要ない。32ビットプログラムはすべてのバージョンのWindowsで動作する。64ビットOSが64ビットプログラムを要求するLinuxとは違う。

LinuxがWindowsより少し速いかどうかも気になる。

ディレクトリ構成はどうすべきだと思うか: /bin32/ /bin64/ それとも /bin/32/ /bin/64/

virtualcoinさん、ありがとう。完璧な比較だ。

32ビットWindows(2310k)から32ビットLinux(2500k)への8%の速度向上は、おそらくLinux上の新しいバージョンのGCC(4.4.3 vs 3.4.5)によるものだ。

32ビットから64ビットLinuxへの15%の速度向上はもっと謎だ。コードは完全に32ビットだ。

うーん、x86-64で追加された8つの追加レジスタが効いているのだと思う。16の状態変数のほとんどをレジスタに保持できれば、SHAにとって大きな違いになるだろう。

ステータスバーの最初のパネルは、メニュー項目にカーソルを合わせた時のヘルプ説明と共有されている。すべてのメニュー項目の説明が空白なので、メニュー上にカーソルがある時に空白に置き換わる。