バージョン0.3.13、アップグレードしてください
バージョン0.3.13が利用可能になった。0/未承認トランザクションに関する潜在的な問題を防ぐためにアップグレードしてほしい。注意：0.3.13は0/未承認トランザクションをまだ使用していない場合の問題を防ぐが、すでに使用してしまった場合は0.3.13.2が必要だ。
変更点：
- 1回の承認があるまで支払いをカウントまたは使用しない。
- 内部バージョン番号を312から31300に変更。
-allowreceivebyipが指定された場合のみIPアドレスで送信されたトランザクションを受け入れる。- DB_PRIVATE Berkeley DBフラグを廃止。
- 1セント未満の端数のお釣りで最後の1セントを送金する際の問題を修正。
- Linuxでの128ビット4-way SSE2の自動検出。
ギャビン・アンドレセン:
- 別のマシンからのJSON-RPC接続を受け入れるオプション
-rpcallowip=。 - LinuxでのSIGTERMによるクリーンシャットダウン。
ダウンロード：http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/
（Mac OSXビルドをしてくれたラズロに感謝！）
注意：Linux 64ビット版のSSE2自動検出は、64ビットモードのAMDでは動作しない。代わりにこちらを試して、正しく動作するか知らせてほしい：http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
-4wayおよび -4way=0で手動でSSE2の使用を制御することもできる。
バージョン0.3.13.2（SVN rev 161）には、すでに0/未承認トランザクションがあり、それをすでに使用した可能性がある場合の改善が含まれている。Windows版のビルドはこちらだ：http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
ウォレットを作成して、それにビットコインを送って、 確認を待ってから、そのウォレットを削除して 以前のコピーを復元すると、クライアントはそのトランザクション を見なくなる。しかし、すべてのブロックを削除して すべてのブロックを再ダウンロードすると、その金額が 表示される。再カウント機能を作ると良いだろう……
ああ！ ウォレットが壊れた。Bitcoinがファイルを閉じなかったため、Dropboxは古すぎるコピーしか保存していなかった。クライアントはウォレットに対する操作が必要ない時にはウォレットを閉じるべきだと思う。どう思う？
それは良いが、自動4way検出がGentoo AMD 64版のクライアントで動いていない。
まだ -4wayスイッチを追加する必要がある。
Dwdollarは、誰かが悪意を持ってか偶然か「確認不能な」トランザクションを送ってきたため、Bitcoin Marketでいくらかのbtcを失った。彼はアップグレードしていなかった。今がアラート機能をテストする良いタイミングかもしれない。
バージョン0.3.13が利用可能になった。
-allowreceivebyipが指定された場合のみIPアドレスで送信されたトランザクションを受け入れる。- 別のマシンからのJSON-RPC接続を受け入れるオプション
-rpcallowip=。
これらのオプションが—helpの出力に表示されていないことに気づいた…—helpにはこれらのオプションの包括的なリストが載っているべきじゃないかな？ （特に、公式リリースのtarballにはmanページやその他のヘルプドキュメントが含まれていないことを考えると）
ただの何気ない質問だけど、結果が次のリリースに反映されるといいな。😊
Dwdollarは、誰かが悪意を持ってか偶然か「確認不能な」トランザクションを送ってきたため、Bitcoin Marketでいくらかのbtcを失った。彼はアップグレードしていなかった。今がアラート機能をテストする良いタイミングかもしれない。
確認されなかったなら、なぜアカウントに入金を認めたんだろう？ ブロック数を確認回数の代わりにカウントしているのかな？ 変な話だ。
確認されなかったなら、なぜアカウントに入金を認めたんだろう？ ブロック数を確認回数の代わりにカウントしているのかな？ 変な話だ。
彼は永遠に承認されない取引からコインを取る取引を送ったので、この取引も永遠に承認されず、したがって失われた（お釣りも含めて）。送った相手が0.3.13を使っていなければ、その人も承認不能な取引を送ることになる。ウイルスのようなものだ。できるだけ早く0.3.13に移行する必要がある。
承認とは何の関係もない。
tarballにmanページを含めるべきだと提案する。
Dwdollarは、誰かが悪意を持ってか偶然か「確認不能な」トランザクションを送ってきたため、Bitcoin Marketでいくらかのbtcを失った。彼はアップグレードしていなかった。今がアラート機能をテストする良いタイミングかもしれない。
それには同意できる。さもないと0承認の取引がネットワークを伝播して多くの人のウォレットを台無しにする可能性がある。
それは良いが、自動4way検出がGentoo AMD 64版のクライアントで動いていない。
まだ
-4wayスイッチを追加する必要がある。
言い忘れていたが、64ビットAMDでは検出がうまくいかないのではないかと疑っていた。信じがたいことだが、AMDは64ビットモードで異なるモデル番号を報告する。
debug.logでCPUIDをgrepして、何が表示されるか教えてもらえないだろうか？ （64ビットAMDを使っているほかの人も）それと、どのAMDチップを使っているの？
64ビットをサポートするすべてのAMDは、より良いSSE2ハードウェアも搭載しているのだろうか？
数人の方にこのスペシャルビルドを実行してもらえないだろうか？ ダストスパムトランザクションを免除し、当面の0/未承認問題を解消する。通過させるブロックが1つあれば、以前のトランザクションを解消できる。このビルドでブロックを生成したら投稿してくれ。
これらはバイナリのみだ。Linux版は64ビットのみだ。http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz
Linux 64ビット版には、64ビットモードのAMD向けcpuid 4-way 128ビットSSE2自動検出の変更が含まれている。テストしてより良いかどうか確認してもらえると助かる。
diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sun Oct 03 20:57:20 2010
+++ new\main.cpp Sun Oct 03 20:57:54 2010
@@ -2831,6 +2831,10 @@
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
+ // AMDは64ビットモードでより低いモデル番号を報告する
+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)
+ fUseSSE2 = true;
+
static bool fPrinted;
if (!fPrinted)
{
@@ -2989,6 +2993,17 @@
// ブロックサイズに基づくトランザクション手数料
int64 nMinFee = tx.GetMinFee(nBlockSize);
+ //////// 一時的なコード
+ if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "")
+ {
+ if (nBestHeight < 91000)
+ nMinFee = 0;
+ if (nBestHeight < 100000 && nTxSize < 2000)
+ nMinFee = 0;
+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)
+ nMinFee = 0;
+ }
+ //////// 一時的なコード
map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);
if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))
diff -u old\serialize.h new\serialize.h
--- old\serialize.h Sun Oct 03 20:57:45 2010
+++ new\serialize.h Sun Oct 03 20:57:54 2010
@@ -22,8 +22,8 @@
class CAutoFile;
static const unsigned int MAX_SIZE = 0x02000000;
-static const int VERSION = 31300;
-static const char* pszSubVer = "";
+static const int VERSION = 31301;
+static const char* pszSubVer = " test1";ArtForzはすでに手数料なしで稼働しており、ネットワークのCPUパワーの20〜30%を持っている。ただし、元の壊れた取引を送った人はウォレットを削除し、ネットワークはこれらの過去の取引を忘れているため、これに基づく取引は承認されない。
ArtForzはすでに手数料なしで稼働しており、ネットワークのCPUパワーの20〜30%を持っている。ただし、元の壊れた取引を送った人はウォレットを削除し、ネットワークはこれらの過去の取引を忘れているため、これに基づく取引は承認されない。
トランザクションは、ノードがブロックチェーンに戻るトランザクションのパスを持つまで、0/未承認として受け入れられたり表示されたりしない。
ウォレット内のトランザクションには、ブロックチェーンに到達するために必要な未記録のトランザクションもすべて一緒にバンドルされている。0/未承認として表示されるトランザクションがある場合、それが依存する以前の未記録のトランザクションもすべて持っており、自分のトランザクションを再ブロードキャストする際にそれらも再ブロードキャストする。
手数料なしのブロックがすでに生成されたのに解決しない場合は、何が問題なのか調べる必要がある。あまり使われないコードの部分だ。それらに依存するトランザクションを持つ全員のウォレットに記録されているはずだ。
マイケル・マーカート元の壊れた取引を送った人はウォレットを削除した
はぁ……ウォレットを別の場所に移動して万が一のために古いコピーを保管しておくのではなく、なぜ削除するのだろうか？ ウォレットは決して削除すべきではない。
tcatmの投稿（2010年10月3日20:10 UTC）動いている。3時間以内にブロックが見つかるはずだ。
再ブロードキャストされたトランザクションを収集するのに時間がかかるかもしれない。より多くのノードをリッスンできるよう、インバウンド接続を受け入れられるようにすると助けになる。3時間でブロックを見つけたとしても、少なくとも数日間は継続して実行し続けてくれ。
ブロック83018（00000000002bba570c3）で大量に処理された。最後に聞いた時点では、nanotubeにまだ未確認のものが1件あった。
追記：nanotubeのトランザクションは最近処理された。0.01未満のトランザクションに依存していなかったので、遅延の理由は分からない。
ShadowOfHarbringerの投稿（2010年10月2日13:00 UTC）それは良いが、自動4way検出がGentoo AMD 64版のクライアントで動いていない。
まだ
-4wayスイッチを追加する必要がある。言い忘れていたが、64ビットAMDでは検出がうまくいかないのではないかと疑っていた。信じがたいことだが、AMDは64ビットモードで異なるモデル番号を報告する。
debug.logでCPUIDをgrepして、何が表示されるか教えてもらえないだろうか？ （64ビットAMDを使っているほかの人も）それと、どのAMDチップを使っているの？
64ビットをサポートするすべてのAMDは、より良いSSE2ハードウェアも搭載しているのだろうか？
$ grep -i cpuid debug.log
CPUID 444d4163 family 16, model 5, stepping 2, fUseSSE2=0/proc/cpuinfo (http://pastebin.com/mkis0AsC)
言い忘れていたが、64ビットAMDでは検出がうまくいかないのではないかと疑っていた。信じがたいことだが、AMDは64ビットモードで異なるモデル番号を報告する。
debug.logでCPUIDをgrepして、何が表示されるか教えてもらえないだろうか？ （64ビットAMDを使っているほかの人も）それと、どのAMDチップを使っているの？
64ビットをサポートするすべてのAMDは、より良いSSE2ハードウェアも搭載しているのだろうか？
これで足りるかな？：
cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 16
model : 2
model name : AMD Phenom(tm) 9850 Quad-Core Processor
stepping : 3
cpu MHz : 2508.353
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs npt lbrv svm_lock
bogomips : 5018.72
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstateEDIT: CPUIDの確認方法もわかった：
CPUID 444d4163 family 16, model 2, stepping 3, fUseSSE2=0ShadowOfHarbringer、あなたのは -4wayの方が速い？
もしそうなら、64ビットをサポートするすべてのAMDが128ビットSSE2を搭載していると考えている。
ここに投稿したスペシャルビルド版はモデル4以上を探す。あなたのが -4wayで速いなら、64ビット対応のすべてのAMDで常にSSE2を使用するように変更すべきだろう。
ShadowOfHarbringer、あなたのは
-4wayの方が速い？
確かに、-4wayありの方が、なしの場合と比べてほぼ2倍速い。
-4wayありで約8500 khash/sec、なしで4500 khash/secが出ている。
ウォレット内のトランザクションには、ブロックチェーンに到達するために必要な未記録のトランザクションもすべて一緒にバンドルされている。0/未承認として表示されるトランザクションがある場合、それが依存する以前の未記録のトランザクションもすべて持っており、自分のトランザクションを再ブロードキャストする際にそれらも再ブロードキャストする。
手数料なしのブロックがすでに生成されたのに解決しない場合は、何が問題なのか調べる必要がある。あまり使われないコードの部分だ。それらに依存するトランザクションを持つ全員のウォレットに記録されているはずだ。
自分のウォレットに、永続的に0/unconfirmed状態のままのトランザクションが1つある。以下はデバッグモードで表示される詳細だ：
Status: 0/unconfirmed
Date: 09/29/2010 12:46
From: unknown
To: 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU (yours, label: gribble stored address)
Credit: 0.03
Net amount: +0.03debug print Credit: 0.03 Inputs:
Transaction: CTransaction(hash=5c05d9, ver=1, vin.size=1, vout.size=1, nLockTime=0) CTxIn(COutPoint(b412a0, 0), scriptSig=3045022049753afb02f58a7b) CTxOut(nValue=0.03000000, scriptPubKey=OP_DUP OP_HASH160 e2ccd6) これを見てもらって、何が問題で、なぜ未確認のままなのかを確認してもらえるとありがたい……
ブロック83018（00000000002bba570c3）で大量に処理された。最後に聞いた時点では、nanotubeにまだ未確認のものが1件あった。
追記：nanotubeのトランザクションは最近処理された。0.01未満のトランザクションに依存していなかったので、遅延の理由は分からない。
明確にしておくと、「最近クリアされた」ものは問題のマイクロ取引とは無関係だ。未承認の問題のものはまだ未承認のままだ。上の投稿の情報を見てくれ。
64ビットをサポートするすべてのAMDは、より良いSSE2ハードウェアも搭載しているのだろうか？
古いAMD Sempron 64は良いSSE2速度を持っていない。これは -4way=0のままにすべきだ。
CPUID 444d4163 family 15, model 44, stepping 2, fUseSSE2=0
サトシ・ナカモトの投稿（2010年10月1日00:34 UTC）バージョン0.3.13が利用可能になった。
-allowreceivebyipが指定された場合のみIPアドレスで送信されたトランザクションを受け入れる。- 別のマシンからのJSON-RPC接続を受け入れるオプション
-rpcallowip=。これらのオプションが—helpの出力に表示されていないことに気づいた…—helpにはこれらのオプションの包括的なリストが載っているべきじゃないかな？ （特に、公式リリースのtarballにはmanページやその他のヘルプドキュメントが含まれていないことを考えると）
ただの素朴な疑問だが、その結果が次のリリースに反映されることを期待している。
コマンドラインスイッチは”bitcoind help”ではなく”bitcoind -?”にリストされている。とはいえその通りで、それらのオプションは”-?”からも欠けている。
ノードをオンラインのままにして、トランザクションb412a0を再ブロードキャストし続けるようにしてくれ。2010年9月29日16:41以降、再ブロードキャストされているのを確認していない。
ノードをオンラインのままにして、トランザクションb412a0を再ブロードキャストし続けるようにしてくれ。2010年9月29日16:41以降、再ブロードキャストされているのを確認していない。
了解、そうする……（0 confのままだったら）またあなたにしつこく聞きに来る前に、どのくらいの時間オンラインにしておけばいいかな？ 😊
（ちなみに、公式の.13クライアントを使っている）
コマンドラインスイッチは”bitcoind help”ではなく”bitcoind -?”にリストされている。とはいえその通りで、それらのオプションは”-?”からも欠けている。
lfm：試してみてくれ、‘-help’ は単なる ‘help’ とは /かなり/ 違う（‘-help’ は ’-?’ と同じだ） 😊
数人の方にこのスペシャルビルドを実行してもらえないだろうか？ ダストスパムトランザクションを免除し、当面の0/未承認問題を解消する。通過させるブロックが1つあれば、以前のトランザクションを解消できる。このビルドでブロックを生成したら投稿してくれ。
このパッチで8ブロック生成した。
ノードをオンラインのままにして、トランザクションb412a0を再ブロードキャストし続けるようにしてくれ。2010年9月29日16:41以降、再ブロードキャストされているのを確認していない。
OK……過去1日間ノードを動かし続けていて、常に他の8ノードに接続していて、現時点でチェーンの最新ブロック（83535）まで進んでいるが、トランザクションは依然として検証されない……ここからどう進めればいい、サトシ？
サトシ・ナカモトの投稿（2010年10月1日00:34 UTC）ああ！ ウォレットが壊れた。Bitcoinがファイルを閉じなかったため、Dropboxは古すぎるコピーしか保存していなかった。クライアントはウォレットに対する操作が必要ない時にはウォレットを閉じるべきだと思う。どう思う？
バージョン0.3.13.2（SVN rev 161）には、すでに使用済みかもしれない0/unconfirmedトランザクションがすでにあった場合のための改善が含まれている。Windowsビルドはこちら：
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
これは自分の壊れたウォレットを開いてくれた。魔法だ！ 😄