オーバーフローバグ深刻
ブロック高 74638 のブロックがネットワークのバグを悪用したようである。整数オーバーフローを利用してトランザクション合計をマイナスにしている。2 つのトランザクション出力は以下の通り：
out Value:92233720368.54(7ffffffffff85ee0) out Value:92233720368.54(7ff ffffffff85ee0)
早急な修正が必要である。
編集： (satoshi) 0.3.10 パッチのダウンロードリンクはこちら： topic 827
より良い修正ができるまで…ほんの少しのテストの後、これでうまくいくようだ：
--- a/main.h
+++ b/main.h
@@ -473,8 +473,12 @@ public:
// Check for negative values
foreach(const CTxOut& txout, vout)
+ {
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
+ if (txout.nValue > 21000000*COIN)
+ return error("CTransaction::CheckTransaction() : txout.nValue over-max");
+ }
if (IsCoinBase())
{
@@ -520,6 +524,8 @@ public:
int64 nValueOut = 0;
foreach(const CTxOut& txout, vout)
{
+ if (txout.nValue > 21000000*COIN)
+ continue; // ignore over-max-value...
if (txout.nValue < 0)
throw runtime_error("CTransaction::GetValueOut() : negative value");
nValueOut += txout.nValue;不正なブロック以前のブロックチェーンの部分を再ダウンロードする必要がある — blkindex.dat と blk0001.dat ファイルを削除すること。私は knightmb のブロックチェーンスナップショットから始めた。
あるいは github からの同じパッチ、http://gist.github.com/525921 で直接適用できる生パッチが得られる。
http://gist.github.com/raw/525921/fe2ad7583f0dd2444caa0b3e24d750bf45cac11b/Quick%20fix%20block%2074652
編集：これを使って直接パッチを適用できなかった。おそらく CRLF の問題だ。
変更を手動で適用し、結果をここにアップロードした：http://yyz.us/bitcoin/patch.bitcoin-gavin-overflow-quick-fix
予備的な変更だ。正しいだろうか？ まだ変更することがある。これがすべてではない。間もなく SVN にコミットする。
bool CheckTransaction() const
{
// コンテキストに依存しない基本チェック
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");
// 負の値とオーバーフロー値のチェック
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}
if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}
return true;
}トピックをスティッキーにしないでくれ、あそこは誰も見ない。バンプするのに十分な投稿があるだろう。
皆さんが生成を停止してくれると助かる。おそらく現在のブランチの周辺でブランチをやり直す必要があり、生成が少ないほどそれが早く完了する。
最初のパッチは SVN rev 132 に入る予定だ。まだアップロードされていない。まず他の雑多な変更を先に出してから、この件のパッチをアップロードする。
残念ながらコミュニティはもう大きすぎて分散しすぎており、何かに対して自発的かつ迅速な対応を多く期待することはできない。特に generation（マイニング）は、多くの人が自動化していてほとんど監視していないだろう。
俺としては問題なさそうだ。
起動時に不正なブロックのハッシュをチェックする処理をハードコードして、それが best-block チェーン上にあれば、そのブロックと後続のブロックを orphan 化することは簡単にできるだろうか？ これを修正するためにチェーンの全部または大部分を再ダウンロードしなければならないのは辛い……
俺としては問題なさそうだ。
起動時に不正なブロックのハッシュをチェックする処理をハードコードして、それがbest-blockチェーン上にあれば、そのブロックと後続のブロックをorphan化することは簡単にできるだろうか？ これを修正するためにチェーンの全部または大部分を再ダウンロードしなければならないのは辛い……
あるいは全ブロックの簡易な再検証だけでもいい。なにしろ以前の 5倍速くなっているのだから。 😉
アップデートを入手したら、knightmbのブロックチェーンをダウンロードするとよい。最新のセキュリティロックインが検証してくれるよう、ブロック 74000より前で終わるような十分に古いものが望ましい。誰かそのリンクを見つけてくれないか？
http://knightmb.dyndns.org/files/bitcoin/blocks/
再ダウンロードする方がいい。
パッチ適用後だが全員がアップグレードする前のブロック検証は非常に遅くなるだろう！おそらく次の難易度調整が大幅に低下するだろう。もちろん、次の調整が来る頃には全員がアップグレードしているだろうから、比較的素早く通過するだろう。
編集：うーん、含まれている情報ファイルがあるようで、それを見れば手がかりが得られるかもしれない。
私たちのような愚かな初心者に、ブロックチェーンをダウンロードしたらどうすればいいか説明してくれないか？
私たちのような愚かな初心者に、ブロックチェーンをダウンロードしたらどうすればいいか説明してくれないか？
それは Bitcoin のデータディレクトリ内のファイルを置き換えることを意味する。何をしているか分かっていない限り推奨しない。
最も簡単で安全な方法は、wallet.dat をバックアップしてからすべてを再ダウンロードすることだ。
パッチが SVN rev 132 にアップロードされた！
現時点での推奨手順：
- シャットダウンする。
- knightmb の blk ファイルをダウンロードする。（blk0001.dat と blkindex.dat ファイルを置き換える）
- アップグレードする。
- 74000 ブロック未満から開始されるはずだ。残りを再ダウンロードさせてほしい。
knightmb のファイルを使いたくない場合は、blk*.dat ファイルを削除するだけでもよいが、全員が同時にブロックインデックス全体をダウンロードするとネットワークにかなりの負荷がかかる。
まもなくリリースをビルドする。
私たちのような愚かな初心者に、ブロックチェーンをダウンロードしたらどうすればいいか説明してくれないか？
Bitcoin が動作していない状態で、Bitcoin のデータディレクトリに置く。Linux なら~/.bitcoin だ。チェーン全体を再ダウンロードしたければ、Bitcoin が動作していない状態でデータディレクトリからファイルを削除するだけだ。
自分は blk00x.dat ファイルと blkindex.dat ファイルをデータディレクトリの外に移動してから、クライアントを再起動するつもりだ。これらが正しいファイルだよな？
編集：いつもアップグレード前にやっているように、ディレクトリ全体もバックアップしておく。
knightmb のファイルを使いたくない場合は、blk*.dat ファイルを削除するだけでもよいが、全員が同時にブロックインデックス全体をダウンロードするとネットワークにかなりの負荷がかかる。
ブロックチェーン <= 64637 の blk*.dat を作るボランティアはいないか？
公式バイナリに known-good なブロックチェーンを同梱して、時間と帯域を節約するというのもありだろうか？
バグ修正には 0.3.9 rc2 の 4-way SSE2 パッチも含まれるだろうか？含まれていることを教えてくれてありがとう、theymos。もし含まれていないなら、時間があるときに別のリリース候補を出してほしい。
davidonpdaからの引用（2010年8月15日 22:02 UTC）74000から無効ブロックまでのトランザクションはどうなる？それらも今や全部無効なのか？
無効なのは、その不正ブロック自身とそれ以降のブロックだけだ。それより前のブロックはすべて有効だ。
[Deleted] Quote from: davidonpda on August 15, 2010, 10:41:29 PM
74637でちょうど持っていると既に言った。
サトシは74,000以前である必要があると言った。
パッチ適用済みのクライアントを持つ人がチェーン全体をダウンロードする限り、できればローカルネットワーク上の別のコンピューターから最適にダウンロードすれば、正しい場所で自動的に停止するはずだ。
[Deleted] Quote from: davidonpda on August 15, 2010, 10:41:29 PM
NewLibertyStandardの投稿（2010年8月15日 22:44 UTC）サトシは74,000以前である必要があると言った。
そうは言っていない。彼は「one」が欲しいと言ったのであって、必要だとは言っていない。微妙な違いだ。 そして「…不正なブロックを含むブロックとそれ以降だけが無効だ。それ以前のブロックはすべて有効だ…」なら、74000 より前である必要はない。
knightmb の時間を節約してあげたかっただけだが、あなたのはどのみち私のより大きい。 😄
ブロックチェーンのダウンロードを更新しないでほしい。誰かのブロックチェーンダウンロードを使う場合、最後まで含むものは望ましくない。やや古いもののほうが良く、最新のブロックをダウンロードして検証できる。
tcatm の 4-way SSE2 SHA-256 はファイル sha256.cpp に入っており、数リビジョン前にすでにアップロードされている。
たった今、Linux 上でのビルドを有効にする makefile.unix である rev 134 をアップロードした。今 Linux で rev 134 をビルドすると -4way スイッチが使える。
ビルドに問題がある場合は、makefile.unix を編集して：
- -DFOURWAYSSE2 を削除
- 以下の行の末尾から obj/sha256.o を削除：
bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o
bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o0.3.10 の Linux ビルドには、私がビルドする際に -4way オプションが含まれる。
Windows 用のパッチダウンロードはこちらだ：
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip
手順：
- シャットダウンする。
- knightmb の blk ファイルをダウンロードし、blk0001.dat と blkindex.dat ファイルを置き換える。
http://knightmb.dyndns.org/files/bitcoin/blocks/http://rapidshare.com/files/413168038/BitcoinBlocks.torrent - 0.3.10 にアップグレードする。
- 74000 ブロック未満から開始され、残りを再ダウンロードするはずだ。
あるいは、blk ファイルのダウンロードが面倒な場合は、以下のようにするだけでよい：
- シャットダウンする。
- blk*.dat を削除（または移動）する。
- 0.3.10 にアップグレードする。
- すべてのブロックを再ダウンロードし、おそらく約 1時間かかる。
ああ、少しわかりにくいな 😕
自分で作る必要がないのか、それともあなたたちが既に持っているものを FTP に上げればいいのか？
Windows マシンからブロックデータをダンプして、Linux/Mac マシンに載せることはできるのか？
[編集] あなたの投稿を見た。では 74,000 未満のものをビルドする。技術者の皆さんの新しいチェーンダウンロードを数分節約できるはずだ。 😉
この焦らしに耐えられない！Jr.メンバー以上で、非公式の SVN rev 134 Linux 64 ビットビルドをコンパイル済みで共有してくれる人はいないだろうか？ええ、公式ビルドが数分後にリリースされることは分かっている。たいして重要ではない。
編集：サトシが先ほどコメントしたので SVN バージョン番号を更新した。
ああ、気にしないでくれ。SVN バージョンが更新されて Windows ビルドもリリースされたので、待つことにする。 😳
[編集] あなたの投稿を見た。では74,000未満のものをビルドする。少なくとも技術者の皆さんの新しいチェーンのダウンロード時間を数分節約できるはずだ。
古いものはそのままにしてくれ！古いほうが良いのだ。何番のブロックだ？60000 から 74000 のどこかであれば問題ない。しばらく前から公開していたものは検証済みで、最善の選択肢だ。
knightmb、ちょうど君の古いファイルを使ってみたが、かなり古いシステムでもキャッチアップにそれほど時間はかからなかった。だから「わざわざやらなくていい」と言いたい。
これについて何か追加すべきだと思う：http://bitcointalk.org/index.php?topic=259.0
必要な時にクライアントに警告メッセージを表示するラベルが必要だ 😊
今は常にウェブサイトを確認しなければならず、これは良くないと思う。
67000 から開始するのは完璧だ。
はい、現時点では 74638 で止まるだろう。より多くのノードがアップグレードして生成するにつれて、ゆっくりと増加し始めるはずだ。
Linux 版のビルドリンクは以下の通りだ。
Linux 版には tcatm の 4-way SSE2 SHA-256 が含まれており、i5 および AMD CPU での生成が高速になる。-4way スイッチを使って有効にし、お使いの環境で高速かどうか確認してほしい。
ダウンロードリンク：
http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe
http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip
http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz
SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz
これについて何か追加すべきだと思う：
http://bitcointalk.org/index.php?topic=259.0
必要な場合に警告メッセージを表示するラベルがクライアントにあるべきだ。 今は常にウェブサイトを確認しなければならず、それは良くないと思う。 同意する。長い間やりたかったのだが、やる時間がなかった。
今のところ、bitcoin-list メーリングリストに登録することもできる。このようなお知らせや主要な新バージョン以外ではほとんど使われていない。
登録/解除ページ：
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
knightmbの投稿（2010年8月15日 22:59 UTC）[編集] 君の投稿を今見た。それなら74,000未満のものを作る。少なくとも君たち技術系の人たちが新しいチェーンをダウンロードする時間を数分節約できるはずだ。
古いやつはそのままにしておいてくれ！古い方がいい。ブロック番号はいくつだ？60000～74000のどこかなら問題ない。しばらく前から提供されているものは検証済みで、最良の選択だ。
ファイルにブロック番号を付けたので、それぞれがどこで止まっているか正確にわかるはずだ。
BitCoinBlocks_Linux_67309.zip BitCoinBlocks_Windows_67300.zip
そのままにしておく。役に立てて嬉しい 😊
… すでにブロック 74638に達している。これはそのブロックが正常なものになったということか？
自分もこの点について混乱していたが、#bitcoin-dev で確認を得た。
不正なブロックは 74638番で、最後の正常なブロックは 74637番だった。番号は 0 から始まるため、クライアントが 74638 ブロックと表示している場合、ブロック 74637番まで、つまり最後の正常なブロックまで取得済みということになる。
同感だ。長いことやりたかったのだが、時間がなかった。
当面は、bitcoin-list メーリングリストを購読するという手もある。今回のような告知や大きな新バージョンの時以外、ほとんど使われていない。
購読・購読解除ページ：
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Good 😄
ともあれ自分は普段ウェブサイトをチェックしているが、初心者ユーザー（今後さらに増えてくる層）向けの解決策を考えていた。
小さなバグでも、初心者や情報を知らないユーザーが多いネットワークでは大問題になり得る。（そういう人たちは http://lists.sourceforge.net/mailman/listinfo/bitcoin-list のようなソースに目を通すことなど決してないだろう 😛）
（英語が下手ですまない、それでも理解してもらえていると願っている 😁）
ポート転送しているノードはこの入力時点で 74642 をカウントしている（36 接続）。他の 3 つのノードはまだ 74638 のままだ（各 8 接続）。
ある意味、これは全員がアップグレードするまで一時的にブロック生成の難易度を下げることになる。そう、遅くなるが、それは各クライアントが難しいハッシュを生成するためにより多くの時間を持つということだ。
影響についての質問：不正なブロックの後、不正なブロックチェーンを使ってトランザクションを送信した。
そのトランザクションの状態はどうなっているのか？ 見る限り、（更新済みの）送信側クライアントのウォレットは差し引かれた金額を表示している。
修正されたチェーンに再組み込みされ、受取人はそれを使用できるようになるのか？
影響についての質問：不正なブロックの後、不正なブロックチェーンを使ってトランザクションを送信した。
ああ、修正されたチェーンに再統合される。トランザクションは消えず、双方で引き続き表示されるが、確認数が 0 に戻り、再び増え始める。
ブロック 74638 以降の不正なチェーンでブロックを生成した場合のみ、そのブロックからの 50 BTC が消える。不正なチェーン内のブロックはまだ成熟していなかったはずだ。
すべての手順を実行した。今、クライアントは 0.3.10 でブロック 74638 で停止した。これで問題ないのか？
まだ 74638 ブロックと表示されているなら、0.3.10 のノードに接続されていない。
今日のところは、以下のパラメーターを追加してみてほしい：
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14
参照
http://bitcointalk.org/index.php?topic=828
クライアントを実行しているほとんどの人はこのメッセージスレッドを読んでいない。では…素朴な質問だ：
- これはバージョン 3.8.1（大災害前）の不正なブロックチェーンを持つクライアントにどのような影響を与え続けるか？
- 3.8.10 にアップグレードしたがブロックチェーンファイルを削除しないクライアントにどのような影響があるか？
クライアントを実行しているほとんどの人はこのメッセージスレッドを読んでいない。では…素朴な質問だ：
- これはバージョン 3.8.1（大災害前）の不正なブロックチェーンを持つクライアントにどのような影響を与え続けますか？
- 3.8.10 にアップグレードしたがブロックチェーンファイルを削除しないクライアントにどのような影響がありますか？
- ノードパワーの 50%以上がアップグレードされ、正しいチェーンが不正なチェーンを追い越せば、0.3.10 ノードは不正なトランザクションが確認を得ることを困難にする。
- blk*.dat ファイルを削除しなかった場合、その 50%への貢献にはなっておらず、正しいチェーンが不正なチェーンを追い越すまで不正なトランザクションが表示され続ける。
ある意味、これは全員がアップグレードするまで一時的にブロック生成の難易度を下げることになる。そう、遅くなるが、それは各クライアントが難しいハッシュを生成するためにより多くの時間を持つということだ。
もちろん、これは難易度が 511.7 に上がった直後に起きた。だから新しい「正しい」ブロックはすべてその難易度と戦うことになる。そしてネットワークの計算力のかなりの部分は不正チェーンの方に行ってしまっているから、新しいブロックを見つけるのに 10分よりずっと長くかかるかもしれない。難易度調整がこれを察知して再び難易度を下げる可能性があるのはどの時点だろうか？
不正なチェーンも、アップグレードするノードが増えるにつれて速度が低下する。
74638 以降、すでに 14 ブロックを生成した。0.3.10 のビルドは約 2～3時間前にアップロードされた。接続しているノードのうち、半数以上がすでに 0.3.10 だ。おそらく、不正なチェーンよりもすでに多くの計算力を持っていると思う。
できるだけ多くの CPU を投入している。ええ、全員がアップグレードするまでちょっと不公平なアドバンテージだな。 🤐 妻の PC が既に新しいブロックを 2 つ生成した（笑）。ツキが彼女の味方のようだ。
… 接続しているノードのうち、半数以上がすでに0.3.10だ。…
素晴らしいニュースだ！でも、どうやってそれを調べたのか？自分自身をできるだけ多くの人に接続させ、バージョンを調査してログを書き出す（通常の Bitcoin の処理に加えて）、特別に調整されたクライアントを書くことを検討していた。
Windows では、findstr /c:“version message” debug.log
不正なチェーンは最近ブロック 74678 にあったようだ。追い越すのが待ちきれない。
http://nullvoid.org/bitcoin/statistix.php の統計では、過去 3時間で 1時間あたり 5 ブロックだった。約 1日前に難易度調整があり、1時間あたり 6 ブロックに戻るはずだった。
不正なチェーンも、アップグレードするノードが増えるにつれて速度が低下する。
74638 以降、すでに 14 ブロックを生成した。0.3.10 のビルドは約 2～3時間前にアップロードされた。接続しているノードのうち、半数以上がすでに 0.3.10 だ。おそらく、不正なチェーンよりもすでに多くの計算力を持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのは良いアイデアだと思う。さもなければネットワークはしばらくかなり分断されたままになるかもしれない。 :/
4b. 現在、ネットワークには良いノードと悪いノード（0.3.10より古いバージョンを実行しているもの）が混在している。古いバージョンを実行しているノードにしか接続しなければ、74638ブロックで止まってしまう。これは、クライアントを次のオプションで起動することで修正できる：
-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14
http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodes
サトシ・ナカモトの投稿（2010年8月16日 02:16 UTC）不正チェーンも、より多くのノードがアップグレードするにつれて鈍化している。
74638以降、すでに14ブロック生成している。0.3.10のビルドは2〜3時間前にアップロードされた。私が接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく不正チェーンよりも多くの計算力をすでに持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのが良いと思う。そうしないとネットワークがしばらく分断されたままになるかもしれない。 :/
古いクライアントは接続させたままにしておきたい。正しいチェーンが不正なチェーンを追い越したときに、彼らも正しいチェーンに戻ってくるからだ。もっとも、古いチェーンが分岐したチェーンをどこまで遡って受け入れるかについて、具体的なことは知らない。
bdonlanの投稿（2010年8月16日 02:39 UTC）サトシ・ナカモトの投稿（2010年8月16日 02:16 UTC）不正チェーンも、より多くのノードがアップグレードするにつれて鈍化している。
74638以降、すでに14ブロック生成している。0.3.10のビルドは2〜3時間前にアップロードされた。私が接続しているノードのうち、半数以上がすでに0.3.10だ。おそらく不正チェーンよりも多くの計算力をすでに持っていると思う。
それでも、古いバージョンからの接続を拒否する別バージョンを出すのが良いと思う。そうしないとネットワークがしばらく分断されたままになるかもしれない。 :/
古いクライアントは接続させたままにしておきたい。正しいチェーンが不正なチェーンを追い越したときに、彼らも正しいチェーンに戻ってくるからだ。もっとも、古いチェーンが分岐したチェーンをどこまで遡って受け入れるかについて、具体的なことは知らない。
古いクライアントは前回リリースのスナップショットまで遡って受け入れるはずだ。だからこの問題がこんなに早く、しかも前回リリースからこれだけ時間が経った後に見つかったのなら、理論上はうまくいくはずだ。これは理論の良いテストだな 😁
Ground Loopの投稿（2010年8月16日 00:29 UTC）影響についての質問：不正ブロックの後、不正ブロックチェーンを使ってトランザクションを送信した。
このトランザクションの状態はどうなる？ 見たところ、（更新後の）送信側クライアントのウォレットには差し引かれた金額が表示されている。
これは修正されたチェーンに取り込まれ直すのか？そして受信者はそれを使えるようになるのか？
そうだ、修正されたチェーンに取り込まれ直す。トランザクションは消えず、両側で引き続き見えるが、コンファメーション数は0に戻ってまたカウントが上がり始める。
50 BTCが消えるのは、ブロック 74638以降に不正チェーンでブロックを生成した場合だけだ。不正チェーンで生成したブロックは、いずれにしてもまだ成熟していないはずだ。
興味深い。このシステムの奥底をどのように進んでいくかを見るのは魅力的だ。 私が生成したのはブロック 73746 だった。 CTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186) 08/12/10 02:35 generated 50.00
そしてそのうち 49.00 を 19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXz に送った（壊れたチェーンを使って）。
今は、そのノードが受信に気付き、新しいチェーンを使うようになるのを待っている。
チェーン全体を削除して再ダウンロードする代わりに、チェーンの末尾を手動で切り落とす RPC コマンドがあると便利ではないか？
この時点で、アップグレードしていないクライアントも正しいチェーンを持っているのか？
はい。唯一の例外は、パッチ未適用のクライアントが別の偽トランザクションを作成し検証に成功した場合だ。アップグレードしていない他のいくつかのノードにその偽ブロックを広められるだろうが、アップグレード済みクライアントの方がパッチ未適用クライアントより多くのパワーを持っているようなので、不正なリンクは長続きせず、アップグレード済みクライアントには広まらない。
未アップグレードのノードはほとんどの場合正しいチェーンを持っているが、依然としてすべてのブロックにオーバーフロートランザクションを含めようとしているため、継続的にフォークして無効なブロックを生成しようとしている。旧バージョンのノードを再起動すると、トランザクションプールが空になるため、トランザクションが再ブロードキャストされるまでしばらくは有効なブロックを生成するかもしれない。0.3.9 以下のノードはまだアップグレードが必要だ。
SVN には、blk*.dat ファイルを手動で削除せずにブロックチェーンを自動的に再編成するために必要なコードが入っている。昨日はそのコードを迅速かつ慎重に書くことができないとわかっていたので、手動の簡易オプションで対応した。