*** 警告 *** 0.3.6に今すぐアップグレードしてください！
できるだけ早く 0.3.6 にアップグレードしてほしい！不正なトランザクションが承認済みとして表示される可能性がある実装上のバグを修正した。バージョン 0.3.6 にアップグレードするまで、ビットコインのトランザクションを支払いとして受け入れないでほしい！
すぐに 0.3.6 にアップグレードできない場合は、アップグレードするまでビットコインノードをシャットダウンすることを勧める。
0.3.6 にはハッシュ計算の高速化も含まれている：
- tcatm による midstate キャッシュ最適化
- BlackEye による Crypto++ ASM SHA-256 生成速度の合計で 2.4倍の高速化。
ダウンロード：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/
Windows および Linux ユーザーの方へ：0.3.5 を入手した場合でも、0.3.6 へのアップグレードが必要だ。
できるだけ早く 0.3.6 にアップグレードしてくれ！ 偽のトランザクションが承認済みとして表示される可能性がある実装バグを修正した。バージョン 0.3.6 にアップグレードするまで、Bitcoin トランザクションを支払いとして受け入れないでほしい！
すぐに 0.3.6 にアップグレードできない場合は、アップグレードするまで Bitcoin ノードをシャットダウンすることをお勧めする。
また、0.3.6 ではハッシュが高速化されている：
- tcatm の功績による midstate キャッシュ最適化
- BlackEye の功績による Crypto++ ASM SHA-256 生成速度の合計高速化は 2.4倍だ。
ダウンロード：
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/
Windows と Linux のユーザーへ：0.3.5 を入手済みでも、0.3.6 にアップグレードする必要がある。
このセキュリティアップデートの素早さには感謝するが、残念ながら Linux ビルドはどれも（32 ビットも 64 ビットも）動かない。ファイルが欠けているからだ。ファイルを自分で見つけてくれば動くと思うが、新しいビルドを使う他の人がどれだけうまくやれるかは分からない。
エラー
./bitcoin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directoryサトシと Olipro は一緒に作業しているのか？ そうでないなら、一緒にやれる可能性はある？ 😊
Olipro が進めている速度改善にはとても満足しているが、bc は安全であってほしいんだ！
至急0.3.5へアップグレードしてほしい！ 不正なトランザクションが受理されてしまう実装上のバグを修正した。バージョン0.3.5にアップグレードするまでは、Bitcoinトランザクションを支払いとして受け取らないでほしい！
Olipro と同様、世にはカスタムビルドを使っている人間が大勢いる――実際、自分も複数のマシンでカスタムビルドを使わざるを得ない。
SVN には必要な更新がすべて入っている、と考えていいのか？
公式 Linux-64bit ビルドを Fedora 13 で実行したところ、ひどく失敗した：
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException() terminate called after throwing an instance of ‘DbRunRecoveryException’ what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
俺の Bitcoin が食われてないことを祈る…
公式Linux-64bitビルドをFedora 13で実行したところ、ひどく失敗した：
Code:************************ EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in CMyApp::OnUnhandledException()terminate called after throwing an instance of ‘DbRunRecoveryException’ what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
俺のBitcoinが食われてないことを祈る…
大丈夫だと思う、こっちも吹っ飛んだ。旧バージョンを実行すれば、コインは全部見えるはずだ。次の Linux リリースに備えてまずバックアップしておけ。
公式 Linux-64bit ビルドを Fedora 13 で実行したところ、ひどく失敗した：
別のマシンでも同じ結果だ。BDB エラーで死亡。64bit Linux の 0.3.5 は問題がある。32bit Linux のビルドと混同していないか？
debug.log の内容：
Bitcoin version 0.3.5 beta
Default data directory /g/g/.bitcoin
Bound to port 8333
Loading addresses...
dbenv.open strLogDir=/garz/bitcoin/data/database strErrorFile=/garz/bitcoin/data/db.log
************************
EXCEPTION: 22DbRunRecoveryException
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery
bitcoin in AppInit()大丈夫だと思う、自分もやられた。古いバージョンを実行すれば、コインは全部見えるはずだ。次のLinuxリリースに備えてまずバックアップを
ダブル ACK 😊
古いバージョン（SVN 117 + listtransactions + getinfo KHPS）は問題なく動作、すべてのビットコインが存在する。そして確かに、「アップグレードしてください」の指示に従う前にバックアップすべきだった…… 😊
[Deleted] Quote from: davidonpda on July 29, 2010, 07:51:38 PM
Windows ユーザーはとりあえず3.5にアップグレードできるか？
はい、Windows XP、2003、7 でテスト済み、すべて問題なく通った。速度向上も楽しめるだろう。😉
[えっ、待った、新バージョンが出るところだ]
まだ SVN を更新する時間がなかった。0.3.6 を待ってくれ、今ビルドしている。その間、ノードをシャットダウンしておいてもかまわない。
SVN をバージョン 0.3.6 に更新した。
0.3.6 の Windows ビルドを Sourceforge にアップロード中だ。その後、Linux を再ビルドする。
ハ！変更内容の 1 つは”0.3.3”を”0.3.6”に更新した部分があるが、それはアップデートの重要な部分ではない。:-)
Windows ビルドを XP、2003、Vista、7（32 ビットと 64 ビットの両方）でテスト済み、クライアントのインストールと実行に問題なし。今のところ順調、Linux クライアントが楽しみだ。😉
0.3.6 の Linux ビルドは古い makefile.unix に戻った。libjpeg を静的リンクしているので、問題はないはずだ。
これでうまく動作しているか？
22DbRunRecoveryException が発生し、以前に他の人のビルドを使用したことがある場合は、database/log.000000*を削除（またはファイルを別の場所に移動）する必要があるかもしれない。
Windows と Linux のユーザーへ：0.3.5 を入手済みでも、0.3.6 にアップグレードする必要がある。
それでも Linux ビルドは依然としてダメだ、これがコンソールに出ているエラーだ。ファイルがあることは確認したが、バージョンが合っていないようだ？
64 ビットクライアントのエラー。32 ビットクライアントも試して、似たようなエラーが出るか見てみる。
./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)これをテストしたマシンはストックビルドしか使っていない。これまでに改造ビルドは一切使っていない。
32 ビットクライアントでも同じエラーだ。
./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)Linux - Mandriva 2010.0 [64 ビットおよび 32 ビット] OS のセットアップ
Linux 用の 0.3.6 バイナリは、Debian squeeze/sid の自分の 2 台のマシン（64bit と 32bit）で問題なく動作した。
私のマシン2台（64ビットと32ビット）ではLinux用の0.3.6バイナリは問題なく動いている
それは知っておく価値がある。こちらが更新するだけで済むかもしれないので、現在インストールされているバージョンを確認している。
私のマシン2台（64ビットと32ビット）ではLinux用の0.3.6バイナリは問題なく動いている
差し支えなければ、成功/失敗の報告時にOS 名と OS バージョンを投稿してほしい。
別のフォーラムメンバーからサトシへの提案を繰り返す：より広い互換性を確保するために、古いLinux OS で Linux バイナリをビルドすべきだ。CentOS 5 くらい古いものでもいいかもしれない（注意：カスタムの openssl、boost、db4、wx ビルドが必要）。
ああ、私のは 2.10.1 にリンクされている。最新にアップデートして解決するか試してみる 😄
[編集] パッケージでは 2.10 が上限で、できなかった
bitcoinexの投稿（2010年7月29日 12:27 UTC）Linux用の0.3.6バイナリは、Debian squeeze/sidの自分の2台のマシン（64bitと32bit）で問題なく動作した。
差し支えなければ、成功/失敗の報告時にOS名とOSバージョンを投稿してほしい。
別のフォーラムメンバーからサトシへの提案を繰り返す：より広い互換性を確保するために、古いLinux OSでLinuxバイナリをビルドすべきだ。CentOS 5くらい古いものでもいいかもしれない（注意：カスタムのopenssl、boost、db4、wxビルドが必要）。
同意する、最先端のディストロパッケージを使っていない我々にとって助かる。😊
bitcoinexの投稿（2010年7月29日 12:27 UTC）Linux用の0.3.6バイナリは、Debian squeeze/sidの自分の2台のマシン（64bitと32bit）で問題なく動作した。
差し支えなければ、成功/失敗の報告時にOS名とOSバージョンを投稿してほしい。
別のフォーラムメンバーからサトシへの提案を繰り返す：より広い互換性を確保するために、古いLinux OSでLinuxバイナリをビルドすべきだ。CentOS 5くらい古いものでもいいかもしれない（注意：カスタムのopenssl、boost、db4、wxビルドが必要）。
すまない。Debian GNU/Linux squeeze/sid でバイナリを確認した。
「./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11’ not found (required by ./bitcoin)」は 0.3.6 から始まった新しい問題ではないよな？ これは 0.3.0 と同じ OS 環境でビルドされたものだ。
残念ながら、0.3.0 の前に Ubuntu 10.04 にアップグレードしてしまった。もうこれ以上アップグレードしない。ダウングレードのために再インストールする時間がいつ取れるかわからないが、少なくともアップグレードしないことで、徐々に問題は解消されるだろう。
v0.3.6 は FreeBSD/i386 7.2、7.3、および FreeBSD/amd64 8.0 で動作する。
警告ひとつなくきれいにコンパイルが通り、問題なく動作しているようだ。
http://bitcointalk.org/index.php?topic=612.0 に挙げられている各点を参考にすれば、Linux バイナリ配布をできるだけ広い層で動かせるようにする助けになるかもしれない。
OpenSUSE の OBS サービスでプロジェクトをビルドできるようにすれば、メンテナはディストリビューション固有のコンパイルを無料で手に入れられるはずだ。
0.3.6 は Win7 Pro 64 ビットで問題なく動作している。
Ubuntu Linux 9.10
エラー：
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11’ not found 😢
Debian テスティング 32 ビットで、いくつかのビルドエラーが出る。すべて以下に類似している：
script.cpp:114: error: ʻOP_NOP1ʼ was not declared in this scope"make clean"または"make"を先にせずに"make bitcoind"しようとした時にこのエラーが出た。bitcoindのビルド手順はヘッダーを先にコンパイルしないが、headers.h.gchも削除しないので、存在する場合は古いヘッダーが使われるようだ。このエラーが出た人は、“make clean”してからビルドを再試行するのが最も簡単な解決策だ。
「./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11’ not found (required by ./bitcoin)」は0.3.6から始まった新しい問題ではないよな？ これは0.3.0と同じOS環境でビルドされたものだ。
残念ながら、0.3.0の前にUbuntu 10.04にアップグレードしてしまった。もうこれ以上アップグレードしない。ダウングレードのために再インストールする時間がいつ取れるかわからないが、少なくともアップグレードしないことで、徐々に問題は解消されるだろう。
変だな、0.3.3 はそのマシンで問題なく動いていた。大した問題ではない、どのみちそのマシンをアップグレードする必要がある。
Ubuntu Linux 9.10
エラー：
/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11’ not found 😢
dpkg -l | egrep "(libc6|glibc)"
# 現在インストールされているバージョンが表示される
# おそらくglibc version 2.10以前がインストールされている。
apt-get update
apt-cache showpkg libc6 | less
# （下の方で）2.11バージョンが利用可能か確認する
# 以下でアップグレードできるかもしれない：
apt-get upgrade libc6
# 上記は本来のDebianシステム用の手順で、Ubuntuでも動くかもしれないDebian テスティング 32 ビットで、いくつかのビルドエラーが出る。すべて以下に類似している：
script.cpp:114: error: OP_NOP1 was not declared in this scope「make clean」や「make」を先に行わずに「make bitcoind」を実行した時にこのエラーが出た。bitcoindのビルド手順ではヘッダーが先にコンパイルされないようだが、headers.h.gchも削除されないため、存在する場合は古いヘッダーが使用される。他にもこのエラーが出た方がいれば、最も簡単な解決策は「make clean」してからビルドを再試行することだ。 プリコンパイル済みヘッダーは実際には必要ない。コンパイルがわずかに速くなるだけだ。廃止しようと思う。それでも、残ったファイルを削除するために、もう一度「make -f makefile.unix clean」を実行するか headers.h.gch を削除する必要がある。
あの GLIBC_2.11 のせいで。アップデートを受け入れないよう注意していたと思っていたのに。
プリコンパイル済みヘッダーは別に必要ない。コンパイルがほんの少し速くなるだけだ。これは取り除こうと思う。とはいえ、残ったファイルを片付けるためには、もう一度「make -f makefile.unix clean」を実行するか、headers.h.gchを削除することを忘れないようにする必要がある。
あの GLIBC_2.11 のせいで。アップデートを受け入れないよう注意していたと思っていたのに。
GLIBC_2.10 版をコンパイルしようと思ったが、チェックエラーを通すためにどんどんインストールしないといけないことに気づいた、笑える。開発パッケージを全部入れた Virtual Box を立ち上げて、仮想マシンの中でやった方が楽になりそうだ。
ハッシュが 2倍速くなることがなぜ重要なのか、誰か理解を助けてくれないか？ 全員がアップグレードしても、コインのインフレ率は変わらない。つまり、アーリーアダプターには「わずかな」優位性があるということだ。これによって「正直なノード」により多くの時間が与えられ、結果として不正なノードが優位を得るのがさらに難しくなる、と言う者もいるだろう。
通貨の最重要要素は分割可能性と固定供給量だ。コインの相対的な価値は、購入可能な商品の供給量に応じて自動的に調整される。だから、まず「生成速度」以外の側面に集中したいと考えるのが筋だと思う。
ハッシュが2倍速くなることがなぜ重要なのか、誰か理解を助けてくれないか？ 全員がアップグレードしても、コインのインフレ率は変わらない。つまり、アーリーアダプターには「わずかな」優位性があるということだ。これによって「正直なノード」により多くの時間が与えられ、結果として不正なノードが優位を得るのがさらに難しくなる、と言う者もいるだろう。
通貨の最重要要素は分割可能性と固定供給量だ。コインの相対的な価値は、購入可能な商品の供給量に応じて自動的に調整される。だから、まず「生成速度」以外の側面に集中したいと考えるのが筋だと思う。
ごく単純に言えば、コイン生成の競争条件を平準化し、ブロック生成を安定したレートで維持できるようにするためだ。もしクライアント側で全員が 100 khash/s に制限されていたら、誰かが制限のないクライアントをコンパイルして、1 台あたり 10,000 khash/s を叩き出せるサーバーファームに載せるだけのことだ。そうなればコイン生成の供給は、サーバーに大金を投じられる人間の手に渡り、それ以外の人々はコインを鋳造しようとする意欲をくじかれる。もしクライアントがトランザクションノードとしてのみ振る舞い、誰もが公平にコイン生成に挑めると信じられるなら、クライアントが常時5 khash/s で生成していようと誰も気にしないだろう。
だから完璧な世界であれば、自分より他人が 2倍3倍速く生成できようと誰も気にしないが、我々は完璧な世界には住んでいないんだ。 😉
BC に自動アップデート機能を組み込むことは可能だろうか？
BC に自動アップデート機能を組み込むことは可能だろうか？
それはもうここで提案済みだ :|
http://bitcointalk.org/index.php?topic=259.0
andy_3_913の投稿（2010年7月30日 07:04 UTC）BCに自動アップデート機能を組み込むことは可能だろうか？
それはもうここで提案済みだ :|
http://bitcointalk.org/index.php?topic=259.0
すまない！😊
これらのビルドを作るのにどれだけ苦労したか想像できる。自分は Ubuntu 9.04 上でプログラムをビルドしようとしているが、パッケージをインストールしてソースをコンパイルし続けても、依存関係を全部見つけられない（笑）。
これらのビルドを作るのにどれだけ苦労したか想像できる。自分は Ubuntu 9.04 上でプログラムをビルドしようとしているが、パッケージをインストールしてソースをコンパイルし続けても、依存関係を全部見つけられない（笑）。
なぜそんなに苦労しているのか理解できない。build-unix.txt の手順に従っただけだ。Boost 1.37 用にちょっとした修正を加えたが、次回 SVN を更新する時にアップロードする。以下に記載する：
依存関係
------------
sudo apt-get install build-essential
sudo apt-get install libgtk2.0-dev
sudo apt-get install libssl-dev
sudo apt-get install libdb4.7-dev
sudo apt-get install libdb4.7++-dev
sudo apt-get install libboost-all-dev（またはlibboost1.37-dev）
wxWidgets
---------
cd /usr/local
tar -xzvf wxWidgets-2.9.0.tar.gz
cd /usr/local/wxWidgets-2.9.0
mkdir buildgtk
cd buildgtk
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfigmakefile.unix にコメントを追加：
# boost 1.37の場合、boostライブラリに-mtを追加
LIBS= \
-Wl,-Bstatic \
-l boost_system \
-l boost_filesystem \
-l boost_program_options \
-l boost_thread \
-l db_cxx \
-l crypto \
-Wl,-Bdynamic \
-l gthread-2.0なぜそんなに苦労しているのか理解できない。build-unix.txtの手順に従っただけだ。Boost 1.37用にちょっとした修正を加えたが、次回SVNを更新する時にアップロードする。以下に記載する：
依存関係
sudo apt-get install build-essential sudo apt-get install libgtk2.0-dev sudo apt-get install libssl-dev sudo apt-get install libdb4.7-dev sudo apt-get install libdb4.7++-dev sudo apt-get install libboost-all-dev (or libboost1.37-dev)
その最後のハイライト部分が原因だった。そのコマンドではすべての libboost パッケージをインストールできない（*でも試した）が、問題の一部は libboost に関する「すべて」をインストールすると文字通りに解釈しすぎたことだ、笑。
実際には、libboost1.37-dev パッケージだけで、すべてのコンパイルエラーが消えた。それ以外は、独自の wxWidgets のコンパイル、Boost 1.4 のコンパイルなど、すべて問題なく動いた。
つまり最後のコマンドは単純に sudo apt-get install libboost1.37-dev
余談だが、Ubuntu 64bit システムでコンパイルしたので、できたプログラムは 64bit 対応になった。いくつかの 64bit システムでテスト中だ。
つまり最後のコマンドは単純に
sudo apt-get install libboost1.37-dev にすればいい ただし、それは boost 1.40 以降（Ubuntu 10.04）では動作しない。その場合は libboost-all-dev を入手する必要がある。
最近 Boost の仕様がいろいろ変わったようで、-mt などの問題もあり、大変だ。
ちなみに、Boost 1.34 を試したが、boost.interprocess がなかった。
Mac OSX 版が利用可能になった。bitcoin.org または SourceForge のリンクを見てくれ。
knightmbの投稿（2010年7月30日 20:04 UTC）だから最後のコマンドは単純に sudo apt-get install libboost1.37-dev でいいんじゃないか
ただし、それはboost 1.40以降（Ubuntu 10.04上）では動かない。そちらではlibboost-all-devを取得する必要がある。
最近Boostは色々と変更されたようで、
-mtなどもあって厄介だ。ところで、Boost 1.34を試したが、boost.interprocess周りが入っていなかった。
Mac OSX版が今利用可能だ。bitcoin.orgまたはSourceForgeのリンクを参照してくれ。
ああ、なるほど、それで腑に落ちた。Ubuntu 10.04 でコンパイルしているとは知らなかった、こっちは Ubuntu 9.04 の視点ですべてを考えていた。
自分の環境では、Ubuntu 9.04 のマシンで 64 ビットのコンパイルを通すのに必要だったのは libboost1.37-dev だけだった。コンパイルする際にディストリの混乱を避けるために、それぞれ用に Virtual Box を複数持っておく必要がありそうだ 😁
認める。 完全に手に負えない領域だ。 orbit@home がオンラインに戻るのを待つことにする。
😄